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Learning Guide for the CST Part II course. This document aims to 
provide background reading to support the lectures - think of it as a free 
downloadable textbook. Chapters 1-5 introduce classical ideas of specifica- 
tion and proof of programs due to Floyd and Hoare. 1 Although much of 
the material is old - see the dates on some of the cited references - it is 
still a foundation for current research. Chapter 6 is a very brief introduction 
to program refinement; this provides rules to 'calculate' an implementation 
from a Hoare-style specification. Chapter 7 is an introduction to the ideas 
of separation logic, an extension of Hoare logic for specifying and verifying 
programs that manipulate pointers. Separation logic builds on early ideas of 
Burstall, but its modern form is due to O'Hearn and Reynolds. 

Note that there may be topics presented in the lectures that are not cov- 
ered in this document and there may be material in this document that is 
not related to the topics covered in the lectures. For example, the topics 
of program refinement and separation logic may only be described very su- 
perficially, if at all. The examination questions will be based on the 
material presented in the lectures. 

The Part II course Hoare Logic has evolved from an earlier Part II course, 
whose web page can be found on my home page (www . cl . cam . ac . uk/~mj eg) . 
Some exam questions from that course might be good exercises (but note that 
some are based on material not covered in this course). A separate document 
containing exercises for the current course is available from the web page. 

Warning. The material here consists of reorganized extracts from lecture 
notes for past courses, together with new material. There is a fair chance that 
notational inconsistencies, omissions and errors are present. If you discover 
such defects please send details to Mike.GordonOcl.cam.ac.uk. 

Acknowledgements. Thanks to Martin Vechev and John Wickerson for 
finding many errors (some serious) in a previous draft of these notes and also 
for suggestions for improving the text. 

MJCG March 2, 2015 



1 Hoare Logic is sometimes called Floyd- Hoare Logic, due to the important contrilml ions 
of Floyd to the underlying ideas. 
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Chapter 1 



Program Specification 



A simple programming language containing assignments, condi- 
tionals, blocks andWRILE-loops is introduced. This is then used to 
illustrate Hoare's notation for specifying the partial correctness of 
programs. Hoare's notation uses formal logic notation to express 
conditions on the values of program variables. This notation is 
described informally and illustrated with examples. 



1.1 Introduction 

In order to prove the correctness of a program mathematically one must first 
specify what it means for it to be correct. In this chapter a notation for 
specifying the desired behaviour of imperative programs is described. This 
notation is due to C.A.R. Hoare. 

Executing an imperative program has the effect of changing the state, 
which, until Chapter 7, we take to be the values of program variables. To 
use such a program, one first establishes an initial state by setting the values 
of some variables to values of interest. One then executes the program. This 
transforms the initial state into a final one. One then inspects the values 
of variables in the final state to get the desired results. For example, to 
compute the result of dividing y into x one might load x and y into program 
variables X and Y, respectively. One might then execute a suitable program 
(see Example 7 in Section 1.4) to transform the initial state into a final state 
in which the variables Q and R hold the quotient and remainder, respectively. 

The programming language used in these notes is described in the next 
section. 
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1.2 A little programming language 

Programs are built out of commands like assignments, conditionals etc. The 
terms 'program' and 'command' are really synonymous; the former will only 
be used for commands representing complete algorithms. Here the term 
'statement' is used for conditions on program variables that occur in correct- 
ness specifications (see Section 1.3). There is a potential for confusion here 
because some writers use this word for commands (as in 'for-statement' [14]). 

We now describe the syntax (i.e. form) and semantics (i.e. meaning) of 
the various commands in our little programming language. The following 
conventions are used: 

1. The symbols V, V\, . . . , V n stand for arbitrary variables. Examples of 
particular variables are X, R, Q etc. 

2. The symbols E, E X) . . . , E n stand for arbitrary expressions (or terms). 
These are things like X + 1, \[2 etc. which denote values (usually 
numbers) . 

3. The symbols S, S 1: . . . , S n stand for arbitrary statements. These are 
conditions like X < Y, X 2 = 1 etc. which are either true or false. 

4. The symbols C, Ci, ... , C n stand for arbitrary commands of our 
programming language; these are described in the rest of this section. 

Terms and statements are described in more detail in Section 1.5. 

1.2.1 Assignments 

Syntax: V : = E 

Semantics: The state is changed by assigning the value of the term E to 
the variable V. All variables are assumed to have global scope. 

Example: X:=X+1 

This adds one to the value of the variable X. 
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1.2.2 Sequences 

Syntax: d; ••• ;C n 

Semantics: The commands Ci, • • • , C n are executed in that order. 

Example: R:=X; X:=Y; Y:=R 

The values of X and Y are swapped using R as a temporary vari- 
able. This command has the side effect of changing the value of 
the variable R to the old value of the variable X. 

1.2.3 Conditionals 

Syntax: IF S THEN d ELSE C 2 

Semantics: If the statement S is true in the current state, then C\ is exe- 
cuted. If S is false, then C 2 is executed. 

Example: IF X<Y THEN MAX:=Y ELSE MAX:=X 

The value of the variable MAX it set to the maximum of the values 
of X and Y. 

1.2.4 WHILE-commands 

Syntax: WHILE S DO C 

Semantics: If the statement S is true in the current state, then C is executed 
and the WHILE-command is then repeated. If S is false, then nothing is done. 
Thus C is repeatedly executed until the value of S becomes false. If S never 
becomes false, then the execution of the command never terminates. 

Example: WHILE -.(X=0) DO X:= X-2 

If the value of X is non-zero, then its value is decreased by 2 and 
then the process is repeated. This WHILE-command will terminate 
(with X having value 0) if the value of X is an even non-negative 
number. In all other states it will not terminate. 
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1.2.5 Summary of syntax 

The syntax of our little language can be summarised with the following spec- 
ification in BNF notation 1 

<command> 

::= <variable> :=<term> 

<command>; ... ; <command> 

IF <statement> THEN <command> ELSE <command> 
| WHILE <statement> DO <command> 

Note that: 

• Variables, terms and statements are as described in Section 1.5. 

• The BNF syntax is ambiguous: for example, it does not specify whether 
IF Sx THEN d ELSE C 2 ; C 3 means (IF S x THEN C x ELSE C 2 ) ; C 3 
or means IF Si THEN d ELSE (C 2 ; C 3 ). We will clarify, whenever 
necessary, using brackets. 

1.2.6 Historical note 

The old Part II course Specification and Verification I was based on a lan- 
guage similar to the one described above, but with additional features: blocks 
(with local variables), FOR-commands and arrays. Blocks and FOR-commands 
don't add fundamentally new ideas so they will not be covered; arrays are 
better handled using separation logic (see Section 7). In the old course I 
used BEGIN and END to group commands, whereas here I just use paren- 
theses. Thus previously I would have written BEGIN C\ ; C 2 END instead of 
(Ci;C 2 ). I mention this as it is may help in reusing old examination ques- 
tions as exercises for this course. 

1.3 Hoare's notation 

In a seminal paper [13] C.A.R. Hoare introduced the notation 2 {P} C {Q}, 
which is sometimes called a Hoare triple, for specifying what a program does. 
In such a Hoare triple: 

1 BNF stands for Backus-Naur form; it is a well-known notation for specifying syntax. 
2 Actually, Hoare's original notation was P {C} Q not {P} C {Q}, but the latter form 
is now more widely used. 
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• C is a program from the programming language whose programs are 
being specified (the language in Section 1.2 in our case). 

• P and Q are conditions on the program variables used in C. Conditions 
on program variables will be written using standard mathematical no- 
tations together with logical operators like A ('and'), V ('or'), -> ('not') 
and =>- ('implies'). These are described further in Section 1.5. 

We say {P} C {Q} is true, if whenever C is executed in a state satisfying 
P and if the execution of C terminates, then the state in which C's execution 
terminates satisfies Q. 

Example: {X = 1} X:=X+1 {X = 2}. Here P is the condition that the value 
of X is 1, Q is the condition that the value of X is 2 and C is the assignment 
command X:=X+1 (i.e. 'X becomes X+l'). {X = 1} X:=X+1 {X = 2} is true. 

An expression {P} C {Q} is called a partial correctness specification; P 
is called its precondition and Q its postcondition. 

These specifications are 'partial' because for {P} C {Q} to be true it is 
not necessary for the execution of C to terminate when started in a state 
satisfying P. It is only required that if C terminates, then Q holds. 

A stronger kind of specification is a total correctness specification. There 
is no standard notation for such specifications. We shall use [P] C [Q\. 

A total correctness specification [P] C [Q] is true if and only if the fol- 
lowing two conditions apply: 

(i) If C is executed in a state satisfying P, then C terminates. 

(ii) After termination Q holds. 

The relationship between partial and total correctness can be informally ex- 
pressed by the equation: 

Total correctness = Termination + Partial correctness. 

Total correctness is what we are ultimately interested in, but it is usu- 
ally easier to prove it by establishing partial correctness and termination 
separately. 

Termination is often straightforward to establish, but there are some well- 
known examples where it is not. For example, the unsolved Collatz conjecture 
is related to whether the program below terminates for all values of X (see 
the exercise below): 
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WHILE X>1 DO 

IF ODD(X) THEN X := (3xX) + l ELSE X := X DIV 2 

(The expression X DIV 2 evaluates to the result of rounding down X/2 to 
a whole number, though since the ELSE-arm of the conditional here is only 
taken if X is even, no rounding is actually needed.) 

The famous mathematician Paul Erdos said about the Collatz conjecture: 
"Mathematics is not yet ready for such problems." He offered $500 for its 
solution. 3 

1.4 Some examples 

The examples below illustrate various aspects of partial correctness specifi- 
cation. 

In Examples 5, 6 and 7 below, T (for 'true') is the condition that is always 
true. In Examples 3, 4 and 7, A is the logical operator 'and', i.e. if P x and 
P2 are conditions, then Pi A P2 is the condition that is true whenever both 
Pi and P 2 hold. 

1. {X = 1} Y:=X {Y = 1} 

This says that if the command Y:=X is executed in a state satisfying the 
condition X = 1 (i.e. a state in which the value of X is 1), then, if the 
execution terminates (which it does), then the condition Y = 1 will hold. 
Clearly this specification is true. 

2. {X = 1} Y:=X {Y = 2} 

This says that if the execution of Y : =X terminates when started in a state 
satisfying X = 1, then Y = 2 will hold. This is clearly false. 

3. {X=x A Y=y} R:=X; X:=Y; Y : =R {X=y A Y=x} 

This says that if the execution of R:=X; X:=Y; Y:=R terminates (which it 
does), then the values of X and Y are exchanged. The variables x and y, 
which don't occur in the command and are used to name the initial values 
of program variables X and Y, are called logical, auxiliary or ghost variables. 

4. {X=xAY=y} X:=Y; Y:=X {X=y A Y=x} 

This says that X : =Y ; Y : =X exchanges the values of X and Y. This is not true. 
3 http : //en . wikipedia. org/wiki/Collatz_conjecture 
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5. {T} C {Q} 

This says that whenever C halts, Q holds. 

6. {P} C {T} 

This specification is true for every condition P and every command C (be- 
cause T is always true). 

7. {T} 



{R < YA X = R + (Y X Q)} 

This is {T} C {R < Y A X = R + (Y x Q)} where C is the command indicated 
by the braces above. The specification is true if whenever the execution of 
C halts, then Q is quotient and R is the remainder resulting from dividing Y 
into X. It is true (even if X is initially negative!). 

In this example a program variable Q is used. This should not be confused 
with the Q used in 5 above. The program variable Q (notice the font) ranges 
over numbers, whereas the postcondition Q (notice the font) ranges over 
statements. In general, we use typewriter font for particular program 
variables and italic font for variables ranging over statements. Although this 
subtle use of fonts might appear confusing at first, once you get the hang of 
things the difference between the two kinds of 'Q' will be clear (indeed you 
should be able to disambiguate things from context without even having to 
look at the font). 



The notation used here for expressing pre- and postconditions is based on 
first-order logic. This will only be briefly reviewed here as readers are as- 
sumed to be familiar with it. 

The following are examples of atomic statements. 



R:=X; 
Q:=0; 

WHILE Y<R DO 
(R:=R-Y; Q:=Q+1) 




1.5 Terms and statements 



F, 



X 



1 



R < Y, 



X = R+(YxQ) 



Statements are either true or false. The statement T is always true and the 
statement F is always false. The statement X = 1 is true if the value of X 
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is equal to 1. The statement R < Y is true if the value of R is less than the 
value of Y. The statement X = R+(YxQ) is true if the value of X is equal to 
the sum of the value of R with the product of Y and Q. 
Statements are built out of terms like: 

X, 1, R, Y, R+(YxQ), YxQ 

Terms denote values such as numbers and strings, unlike statements which 
are either true or false. Some terms, like 1 and 4 + 5, denote a fixed value, 
whilst other terms contain variables like X, Y, Z etc. whose value can vary. 
We will use conventional mathematical notation for terms, as illustrated by 
the examples below: 

X, Y, Z, 
1, 2, 325, 
-X, -(X+l), (XxY)+Z, 

a/CI+X 2 ) , X!, sin(X), rem(X,Y) 

T and F are atomic statements that are always true and false respectively. 
Other atomic statements are built from terms using predicates. Here are 
some more examples: 

ODD(X), PRIME(3), X=l, (X+1) 2 >X 2 

ODD and PRIME are examples of predicates and = and > are examples of 
infixed predicates. The expressions X, 1, 3, X+l, (X+l) 2 , X 2 are examples of 
terms. 

Compound statements are built up from atomic statements using the 
following logical operators: 

(not) 
A (and) 
V (or) 
=>- (implies) 

(if and only if) 

Suppose P and Q are statements, then: 
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• ->P is true if P is false, and false if P is true. 

• P A Q is true whenever both P and Q are true. 

• P V Q is true if either P or Q (or both) are true. 

• P Q is true if whenever P is true, then Q is true also. By con- 

vention we regard P =>■ Q as being true if P is false. In fact, 
it is common to regard P =>- Q as equivalent to -P V Q; 
however, some philosophers called intuitionists disagree with 
this treatment of implication. 

• P ^ Q is true if P and Q are either both true or both false. In fact 

P Q is equivalent to (P Q) A (Q P). 

Examples of statements built using the connectives are: 
ODD (X) V EVEN (X) X is odd or even. 

^(PRIMECX) =>■ ODD(X)) It is not the case that if X is 
prime, then X is odd. 

X < Y X < Y 2 If X is less than or equal to Y, 

then X is less than or equal to 
Y 2 . 

To reduce the need for brackets it is assumed that -> is more binding than A 
and V, which in turn are more binding than =^ and <^>. For example: 

-P A Q is equivalent to (-P) A Q 

P A Q R is equivalent to (P A Q) =>• R 

PAQo^RVS is equivalent to (P A Q) & ((-./?) V S) 
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Chapter 2 



Hoare logic 



The idea of formal proof is discussed. Hoare logic (also called 
Floyd- Hoare logic) is then introduced as a method for reasoning 
formally about programs. 



In the last chapter three kinds of expressions that could be true or false were 
introduced: 

(i) Partial correctness specifications {P} C {Q}. 

(ii) Total correctness specifications [P] C [Q]. 

(iii) Statements of mathematics (e.g. (X + l) 2 = X 2 + 2 x X + 1). 

It is assumed that the reader knows how to prove simple mathematical state- 
ments like the one in (iii) above. Here, for example, is a proof of this fact. 



1. 


(X+l) 2 


= (X+l) X (X+l) 


Definition of () 2 . 


2. 


(X+l) X (X+l) 


= (X+ 1) X X + (X + 1) X 1 


Left distributive law 








of x over +. 


3. 


(X+l) 2 


= (X + 1) X X + (X + 1) X 1 


Substituting line 2 








into line 1. 


4. 


(X+l) X 1 


= X+1 


Identity law for 1. 


5. 


(X+l) x X 


=XxX+lxX 


Right distributive law 








of x over +. 


6. 


(X+l) 2 


=XxX+lxX+X+l 


Substituting lines 4 








and 5 into line 3. 


7. 


1 X X 


= X 


Identity law for 1. 


8. 


(X+l) 2 


=XXX+X+X+1 


Substituting line 7 








into line 6. 


9. 


X X X 


= x 2 


Definition of () 2 . 


10. 


x + x 


= 2 x X 


2=1+1, distributive la 


11. 


(X+l) 2 


= X 2 + 2xX+l 


Substituting lines 9 








and 10 into line 8. 
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This proof consists of a sequence of lines, each of which is an instance 
of an axiom (like the definition of () 2 ) or follows from previous lines by a 
rule of inference (like the substitution of equals for equals). The statement 
occurring on the last line of a proof is the statement proved by it (thus 
(X+l) 2 = X 2 + 2xX+lis proved by the proof above). 

To construct formal proofs of partial correctness specifications axioms 
and rules of inference are needed. This is what Hoare logic provides. The 
formulation of the deductive system is due to Hoare [13], but some of the 
underlying ideas originated with Floyd [9]. 

A proof in Hoare logic is a sequence of lines, each of which is either an 
axiom of the logic or follows from earlier lines by a rule of inference of the 
logic. 

The reason for constructing formal proofs is to try to ensure that only 
sound methods of deduction are used. With sound axioms and rules of infer- 
ence, one can be confident that the conclusions are true. On the other hand, 
if any axioms or rules of inference are unsound then it may be possible to 
deduce false conclusions; for example: 



1. x -1 = V-l x -1 Reflexivity of =. 

2. x -1 = (v 7 -!) x (v 7 -!) Distributive law of over x. 

3. V-l x -1 = (v^T) 2 Definition of () 2 . 

4. y/— 1 x — 1 = — 1 definition of ^T. 

5. VT =-1 As-lx-l = l. 

6. 1 =-1 As v / T=l. 

A formal proof makes explicit what axioms and rules of inference are used 
to arrive at a conclusion. It is quite easy to come up with plausible rules for 
reasoning about programs that are actually unsound. Proofs of correctness of 
computer programs are often very intricate and formal methods are needed 
to ensure that they are valid. It is thus important to make fully explicit the 
reasoning principles being used, so that their soundness can be analysed. 

For some applications, correctness is especially important. Examples in- 
clude life-critical systems such as nuclear reactor controllers, car braking sys- 
tems, fly- by- wire aircraft and software controlled medical equipment. There 
was a legal action resulting from the death of several people due to radiation 
overdoses by a cancer treatment machine that had a software bug [15]. For- 
mal proof of correctness provides a way of establishing the absence of bugs 
when exhaustive testing is impossible (as it almost always is). 

The Hoare deductive system for reasoning about programs will be ex- 
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plained and illustrated. The mathematical analysis of the soundness and 
completeness of the system is discussed in Section 4. 

2.1 Axioms and rules of Hoare logic 

As discussed at the beginning of this chapter, a formal proof of a statement is 
a sequence of lines ending with the statement and such that each line is either 
an instance of an axiom or follows from previous lines by a rule of inference. 
If S is a statement (of either ordinary mathematics or Hoare logic) then we 
write h S to mean that S has a proof. The statements that have proofs are 
called theorems. As discussed earlier, in these notes only the axioms and 
rules of inference for Hoare logic are described; we will thus simply assert 
h S if S is a theorem of mathematics without giving any formal justification. 
Of course, to achieve complete rigour such assertions must be proved, but for 
details of how to do this are assumed known (e.g. from the Logic and Proof 
course) . 

The axioms of Hoare logic are specified below by schemas which can be 
instantiated to get particular partial correctness specifications. The inference 
rules of Hoare logic will be specified with a notation of the form: 

h 5i, ... , h S n 
h S 

This says the conclusion h S may be deduced from the h5i,...,h S n , which 
are the hypotheses of the rule. The hypotheses can either all be theorems of 
Hoare logic (as in the sequencing rule below), or a mixture of theorems of 
Hoare logic and theorems of mathematics (as in the rule of preconditioning 
strengthening described in Section 2.1.2). 

2.1.1 The assignment axiom 

The assignment axiom represents the fact that the value of a variable V after 
executing an assignment command V : =E equals the value of the expression 
E in the state before executing it. To formalise this, observe that if a state- 
ment P is to be true after the assignment, then the statement obtained by 
substituting E for V in P must be true before executing it. 

In order to say this formally, define PIE/V~\ to mean the result of re- 
placing all occurrences of V in P by E. Read P IE /VI as 'P with E for V\ 
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For example, 

(X+l > X) [Y+Z/X] = ((Y+Z) + l > Y+Z) 
The way to remember this notation is to remember the 'cancellation law' 

VIE/V] = E 
which is analogous to the cancellation property of fractions 

v x (e/v) = e 

The Hoare assignment axiom 

h {PIE /V]} V:=E {P} 

Where V is any variable, E is any expression, P is any statement and 
the notation P\_E/V~\ denotes the result of substituting the term E for 
all occurrences of the variable V in the statement P. 

Instances of the assignment axiom are: 

1. h {Y = 2} X := 2 {Y = X} 

2. h {X + 1 = n + 1} X := X + 1 {X = n + 1} 

3. h {E = E} X := E {X = E} (if X does not occur in E). 

Many people feel the assignment axiom is 'backwards' from what they 
would expect. Two common erroneous intuitions are that it should be as 
follows: 

(i) h {P}V:=E {PIV/E1}. 

Where the notation P [V/ E~\ denotes the result of substituting V for 
E in P. 

This has the clearly false consequence that h {X=0} X:=l {X=0}, since 
the (X=0) [X/l] is equal to (X=0) as 1 doesn't occur in (X=0). 

(ii) h {P} V:=E {PIE /VI}. 

This has the clearly false consequence h {X=0} X:=l {1=0} which 
follows by taking P to be X=0, V to be X and E to be 1. 
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The fact that it is easy to have wrong intuitions about the assignment 
axiom shows that it is important to have rigorous means of establishing the 
validity of axioms and rules. We will go into this topic later in Chapter 4 
where we give a formal semantics of our little programming language and 
then to prove that the axioms and rules of inference of Hoare logic are sound. 
Of course, this process will only increase our confidence in the axioms and 
rules to the extent that we believe the correctness of the formal semantics. 
The simple assignment axiom above is not valid for 'real' programming lan- 
guages. For example, work by G. Ligler [17] showed that it failed to hold in 
six different ways for the (now obsolete) language Algol 60. 

There is a 'forwards' version of the assignment axioms which is some- 
times called Floyd's assignment axiom because it corresponds to the original 
semantics of assignment due to Floyd [9]. In this rule below, the existen- 
tially quantified variable v is the value of V in the state before executing 
the assignment (the initial state). The postcondition asserts that after the 
assignment, the value of V is the value of E evaluated in the initial state 
(hence E[v/V]) and the precondition evaluated in the initial state (hence 
P[v/V~\) continues to hold. 

The Floyd assignment axiom 

h {P}V:=E{3v. (V = Elv/V\) A Piv/Vl} 
Where v is a new variable (i.e. doesn't equal V or occur in P or E) 

An example instance is: 

h {X=l} X:=X+1 {3v. X = X+l[u/X] A X=l[u/X]} 
Simplifying the postcondition of this: 

h {X=l} X:=X+1 {3v. X = X+l[u/X] A X=l[u/X]} 

h {X=l} X:=X+1 {3v. X = v + 1 A v = 1} 

h {X=l} X:=X+1 {3v. X = 1 + 1 A v = 1} 

h {X=l} X:=X+1 {X = 1 + 1 A 3v. v = 1} 

h {X=l} X:=X+1 {X = 2 A T} 

h {X=l} X:=X+1 {X = 2} 
The Floyd assignment axiom is equivalent to standard one but harder to 
use because of the existential quantifier that it introduces. However, it is an 
important part of separation logic. 
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The Hoare assignment axiom is related to weakest preconditions (see 
Section 4.3.3) and the Floyd assignment axiom to strongest postconditions 
(see Section 4.4.1). As will be explained in the sections mentioned in the 
previous sentence: 

Hoare assignment axiom: {wlp ( V : =E , Q) } V : =E {Q} 

Floyd assignment axiom: {P} V : =E {sp (V : =E , P) } 

where wlpCC.Q) and sp (C ,P) denote the weakest liberal precondition and 
strongest postcondition, respectively (see sections 4.3.3 and 4.4.1). 

One way that our little programming language differs from real languages 
is that the evaluation of expressions on the right of assignment commands 
cannot 'side effect' the state. The validity of the assignment axiom depends 
on this property. To see this, suppose that our language were extended so 
that it contained expressions of the form (C ;E) , where C is a command and 
E an expression. Such an expression is evaluated by first executing C and 
then evaluating E and returning the resulting value as the value of (C;E). 
Thus the evaluation of the expression may cause a 'side effect' resulting from 
the execution of C. For example (Y:=l; 2) has value 2, but its evaluation 
also 'side effects' the variable Y by storing 1 in it. If the assignment axiom 
applied to expressions like (C\E), then it could be used to deduce: 

h {Y=0} X:=(Y:=1; 2) {Y=0} 

(since (Y=0) [E/X] = (Y=0) as X does not occur in (Y=0)). This is clearly 
false, as after the assignment Y will have the value 1. 

2.1.2 Precondition strengthening 

The next rule of Hoare logic enables the preconditions of (i) and (ii) on page 
20 to be simplified. Recall that 

h Si, ... , h S n 
h s 



means that h S can be deduced from h Si,..., h S n . 

Using this notation, the rule of precondition strengthening is 
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Precondition strengthening 

h p =» p', h {p'} c m 

h {P} C {Q} 



Examples 

1. From the arithmetic fact h X=n =>- X+l=n+l, and 2 on page 20 it follows 
by precondition strengthening that 

h {X = n} X := X + 1 {X = n + 1}. 

The variable n is an example of an auxiliary (or ghost) variable. As described 
earlier (see page 12), auxiliary variables are variables occurring in a partial 
correctness specification {P} C {Q} which do not occur in the command C. 
Such variables are used to relate values in the state before and after C is 
executed. For example, the specification above says that if the value of X is 
n, then after executing the assignment X:=X+1 its value will be n+1. 

2. From the logical truth h T =>- (E=E) , and 3 on page 20 one can deduce 
that if X is not in E then: 

h {T} X :=E {X =E} 



2.1.3 Postcondition weakening 

Just as the previous rule allows the precondition of a partial correctness 
specification to be strengthened, the following one allows us to weaken the 
postcondition. 



Postcondition weakening 

h {P}C{Q>}, hQ'4( 
H {P} C {Q} 
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Example: Here is a little formal proof. 

1. h {R=X A 0=0} Q : =0 {R=X A Q=0} 

2. h R=X R=XA0=0 

3. h {R=X} Q=0 {R=X A Q=0} 

4. h R=XAQ=0 R=X+(Y x Q) 

5. h {R=X} Q:=0 {R=X+(Y x Q)} 



By the assignment axiom. 
By pure logic. 

By precondition strengthening. 

By laws of arithmetic. 

By postcondition weakening. 



The rules precondition strengthening and postcondition weakening are 
sometimes called the rules of consequence. 

2.1.4 Specification conjunction and disjunction 

The following two rules provide a method of combining different specifications 
about the same command. 



Specification conjunction 

h {Pi} C {gi}, h {P 2 } C {Q 2 } 
h {Pi A P 2 } C {Qi A Q 2 } 

Specification disjunction 

h {P,} C {Q 1 }, h {P 2 } g {Q 2 } 
h {P x V P 2 } C {Qi V Q 2 } 



These rules are useful for splitting a proof into independent bits. For ex- 
ample, they enable h {P} C {Qi AQ 2 } to be proved by proving separately 
that both h {P} C {Q x } and h {P} C {Q 2 }- 

The rest of the rules allow the deduction of properties of compound com- 
mands from properties of their components. 



2.1.5 The sequencing rule 

The next rule enables a partial correctness specification for a sequence C\ ; C 2 
to be derived from specifications for C\ and C 2 . 
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The sequencing rule 

h {P} d {Q}, h {Q} C 2 {R} 
\- {P}C i; C 2 {R} 

Example: By the assignment axiom: 

(i) h {X=xAY=y} R:=X {R=xAY=y} 

(ii) h {R=xAY=y} X:=Y {R=xAX=y} 

(iii) h {R=xAX=y} Y:=R {Y=xAX=y} 
Hence by (i), (ii) and the sequencing rule 

(iv) h {X=xAY=y} R:=X; X:=Y {R=xAX=y} 
Hence by (iv) and (iii) and the sequencing rule 

(v) h {X=xAY=y} R:=X; X:=Y; Y:=R {Y=xAX=y} 



2.1.6 The derived sequencing rule 

The following rule is derivable from the sequencing and consequence rules. 



The derived sequencing rule 






H {Pi} Ci {Qi} 


1- Qi P2 


h {P 2 } C 2 {Q 2 } 


l- Q 2 ^ P 3 


H {P n } C n {Q n } 


l- Qn => Q 


H {P}C i; ... 


; C7 B {Q} 



The derived sequencing rule enables (v) in the previous example to be 
deduced directly from (i), (ii) and (iii) in one step. 
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2.1.7 The conditional rule 

The conditional rule 

h {PAS} Ci {Q}, h {PA -^S} C 2 {Q} 
h {P} IF S THEN d ELSE C 2 {Q} 



Example: Suppose we are given that 

(i) h X>Y max(X,Y)=X 

(ii) h Y>X =>■ max(X,Y)=Y 

Then by the conditional rule (and others) it follows that 

h {T} IF X>Y THEN MAX:=X ELSE MAX:=Y {MAX=max(X,Y)} 



2.1.8 The WHILE-rule 

If h {PAS'} C {P}, we say: P is an invariant of C whenever S holds. The 
WHILE-rule says that if P is an invariant of the body of a WHILE-command 
whenever the test condition holds, then P is an invariant of the whole WHILE- 
command. In other words, if executing C once preserves the truth of P, then 
executing C any number of times also preserves the truth of P. 

The WHILE-rule also expresses the fact that after a WHILE-command has 
terminated, the test must be false (otherwise, it wouldn't have terminated). 



The WHILE-rule 

h {PAS} C {P} 
h {P} WHILE S DO C {P A -^S} 



Example: By earlier rules: 
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h {X=R+(YxQ)} R:=R-Y; Q:=Q+1 {X=R+(YxQ)} 
Hence by precondition strengthening 

h {X=R+(YxQ)AY<R} R:=R-Y; Q:=Q+1 {X=R+(YxQ)} 
Hence by the WHILE-rule (with P = 'X=R+(YxQ)') 

(i) h {X=R+(YxQ)} 

WHILE Y<R DO (R:=R-Y; Q:=Q+1) 
{X=R+(YxQ)A^(Y<R)} 

By applying the assignment axiom twice, it is easy to deduce that 

(ii) h {T} R:=X; Q:=0 {X=R+(YxQ)} 

Hence by (i) and (ii), the sequencing rule and postcondition weakening 

h {T} 
R:=X; 
Q:=0; 

WHILE Y<R DO (R:=R-Y; Q:=Q+1) 
{R<YAX=R+(YxQ)} 

With the exception of the WHILE-rule, all the axioms and rules described 
so far are sound for total correctness as well as partial correctness. This is 
because the only commands in our little language that might not terminate 
arc WHILE-commands. Consider now the following proof: 

1. h {T} X:=0 {T} (assignment axiom) 

2. h {TAT}X:=0{T} (precondition strengthening) 

3. h {T} WHILE T DO X:=0 {T A ^T} (2 and the WHILE-rule) 

If the WHILE-rule were true for total correctness, then the proof above 
would show that: 

h [T] WHILE T DO X:=0 [TAnT] 

but this is clearly false since WHILE T DO X : =0 does not terminate, and even 
if it did then T A ->T could not hold in the resulting state. 
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2.1.9 The FOR-rule 

It is quite hard to capture accurately the intended semantics of FOR- 
commands in Floyd-Hoare logic. Axioms and rules are given here that appear 
to be sound, but they are not necessarily complete (see Section ??). An early 
reference on the logic of FOR-commands is Hoare's 1972 paper [14]; a com- 
prehensive treatment can be found in Reynolds [?]. 

The intention here in presenting the FOR-rule is to show that Floyd-Hoare 
logic can get very tricky. All the other axioms and rules were quite straight- 
forward and may have given a false sense of simplicity: it is very difficult 
to give adequate rules for anything other than very simple programming 
constructs. This is an important incentive for using simple languages. 

One problem with FOR-commands is that there are many subtly different 
versions of them. Thus before describing the FOR-rule, the intended semantics 
of FOR-commands must be described carefully. In these notes, the semantics 
of 

FOR V:=E 1 UNTIL E 2 DO C 

is as follows: 

(i) The expressions E 1 and E 2 are evaluated once to get values t\ and e 2 , 
respectively. 

(ii) If either e\ or e 2 is not a number, or if e\ > e 2 , then nothing is done. 

(iii) If C\ < e 2 the FOR-command is equivalent to: 

BEGIN VAR V ; 

V:= ei ; C; V:= ei +1; C ; ... ; V:=e 2 ; C 
END 

i.e. C is executed (e 2 — ei)+l times with V taking on the sequence 
of values ei, ei + 1, ... , e 2 in succession. Note that this description 
is not rigorous: 'ei' and 'e 2 ' have been used both as numbers and 
as expressions of our little language; the semantics of FOR-commands 
should be clear despite this. 

FOR-rules in different languages can differ in subtle ways from the one 
here. For example, the expressions E 1 and E 2 could be evaluated at each 
iteration and the controlled variable V could be treated as global rather than 
local. Note that with the semantics presented here, FOR-commands cannot 
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go into infinite loops (unless, of course, they contain non-terminating WHILE- 
commands) . 

To see how the FOR-rule works, suppose that 

h {P} C {PLV+l/V]} 
Suppose also that C does not contain any assignments to the variable V. If 
this is the case, then it is intuitively clear (and can be rigorously proved) 
that 

h {(V = v)}C {(V = v)} 
hence by specification conjunction 

h {P A (V = v)} C {P[V+1/V] A(V = v)} 
Now consider a sequence 

V:=v; C. 
By Example 2 on page 23, 

h {Plv/V]} V:=v {P A{V = v)} 
Hence by the sequencing rule 

h {Plv/V]} V:=v; C {PLV+l/V] A (V = v)} 
Now it is a truth of logic alone that 

h PW+l/V] A(V = v) => Plv+1/Vl 
hence by postcondition weakening 

h {Plv/Vl} V:=v; C {Plv+1/V]} 

Taking v to be e 1; ei+1, . . . , e 2 

h {P[ei/y]} V:= ei ;C {P[e 1+ l/V]} 

h {P[ ei +l/y]} \/:= ei + l; C {Ple.+2/V]} 

\- {Ple 2 /V]} V:=e 2 ;C {P[e 2 +1/F]} 
Hence by the derived sequencing rule: 

{Ple 1 /V]} V:=e x ; C ; V:= ei +1; ... ; V:=e 2 ; C {P[e 2 +1/V\} 
This suggests that a FOR-rule could be: 

h {P} C {PIV+l/V]} 

h {PCPi/V]} FOR V : =Pi UNTIL P 2 DO C {P[P 2 +l/V]} 

Unfortunately, this rule is unsound. To see this, first note that: 
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1. h {Y+1=Y+1} X:=Y+1 {X=Y+1} (assignment axiom) 

2. h {T} X:=Y+1 {X= Y+l} (1 and precondition strengthening) 

3. h X=Y =>- T (logic: 'anything implies true') 

4. h {X=Y} X:=Y+1 {X=Y+1} (2 and precondition strengthening) 

Thus if P is 'X=Y' then: 

h {P} X:=Y+1 {P[Y+l/Y]} 

and so by the FOR-rule above, if we take V to be Y, E x to be 3 and E 2 to be 
1, then 

h { X=3, } FOR Y:=3 UNTIL 1 DO X:=Y+1 { X=2, } 
P[3/Y] P[l+1/Y] 

This is clearly false: it was specified that if the value of E x were greater than 
the value of E 2 then the FOR-command should have no effect, but in this 
example it changes the value of X from 3 to 2. 

To solve this problem, the FOR-rule can be modified to 

h {P} C {PLV+l/V]} 

h {pIeJV] A Pi < E 2 } FOR V7=E 1 UNTIL E 2 DO C {P[P 2 +l/V]} 

If this rule is used on the example above all that can be deduced is 

h {X=3 A 3 < 1 } FOR Y:=3 UNTIL 1 DO X:=Y+1 {X=2} 

never true! 

This conclusion is harmless since it only asserts that X will be changed if the 
FOR-command is executed in an impossible starting state. 

Unfortunately, there is still a bug in our FOR-rule. Suppose we take P to 
be £ Y=1', then it is straightforward to show that: 

h {Y=l^} Y:=Y-1 { Y+l=l } 
P P[Y+1/Y] 

so by our latest FOR-rule 

h { 1=1, A 1 < 1} FOR Y:=l UNTIL 1 DO Y:=Y-1 { 2=1, } 
P[l/Y] P[l+1/Y] 
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Whatever the command does, it doesn't lead to a state in which 2=1. The 
problem is that the body of the FOR-command modifies the controlled vari- 
able. It is not surprising that this causes problems, since it was explicitly 
assumed that the body didn't modify the controlled variable when we mo- 
tivated the FOR-rule. It turns out that problems also arise if any variables 
in the expressions E 1 and E 2 (which specify the upper and lower bounds) 
are modified. For example, taking P to be Z=Y, then it is straightforward to 
show 

h {,Z=Y} Z:=Z+1 { Z=Y+1 } 
P P[Y+1/Y] 
hence the rule allows us the following to be derived: 

h { Z=l, A 1 < Z} FOR Y:=l UNTIL Z DO Z:=Z+1 { Z=Z+1 } 
P[l/Y] P[Z+l/Y] 

This is clearly wrong as one can never have Z=Z+1 (subtracting Z from both 
sides would give 0=1). One might think that this is not a problem because 
the FOR-command would never terminate. In some languages this might be 
the case, but the semantics of our language were carefully defined in such a 
way that FOR-commands always terminate (see the beginning of this section). 

To rule out the problems that arise when the controlled variable or vari- 
ables in the bounds expressions, are changed by the body, we simply impose 
a side condition on the rule that stipulates that the rule cannot be used in 
these situations. A debugged rule is thus: 



The FOR-rule 




h {P A (E 1 < V) A (V < E 2 )} C {PIV+l/Vl} 




h {P[P!/1/]A(Pi<P 2 )} FOR V := Pi UNTIL P 2 DO C {P[E 2 


+1/V1} 


where neither V, nor any variable occurring in E 1 or E 2 , is assig 


ned to in 


the command C. 





This rule does not enable anything to be deduced about FOR-commands 
whose body assigns to variables in the bounds expressions. This precludes 
such assignments being used if commands are to be reasoned about. The 
strategy of only defining rules of inference for non-tricky uses of constructs 
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helps ensure that programs are written in a perspicuous manner. It is possible 
to devise a rule that does cope with assignments to variables in bounds 
expressions, but it is not clear whether it is a good idea to have such a rule. 

The FOR-axiom 

To cover the case when E 2 < E ly we need the FOR-axiom below. 

The FOR-axiom 

h {P A (E 2 < EO} FOR V := E x UNTIL E 2 DO C {P} 

This says that when E 2 is less than E 1 the FOR-command has no effect. 
Example: By the assignment axiom and precondition strengthening 
h {X = ((N-l)xN) DIV 2} X:=X+N {X=(Nx(N+l)) DIV 2} 
Strengthening the precondition of this again yields 

h {(X=((N-lxN) DIV 2)A(1<N)A(N<M)} X:=X+N {X=(Nx(N+l)) DIV 2} 

Hence by the FOR-rule 

h {(X=((l-l)xl) DIV 2)A(1<M)} 
FOR N:=l UNTIL M DO X:=X+N 
{X=(Mx(M+l)) DIV 2} 

Hence 

h {(X=0)A(1<M)} FOR N:=l UNTIL M DO X:=X+N {X=(Mx(M+l)) DIV 2} 

Note that if 

(i) h {P} C {PIV+l/Vl}, or 

(ii) h {PA (E 1 < V)} C {PIV+1/V1}, or 
(hi) h {PA(V<E 2 )} C {PIV+l/V]} 

then by precondition strengthening one can infer 
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h {PA {E 1 < V) A (V < E 2 )} C {P IV+1/V1 } 

The separate FOR-rule and FOR-axiom are a bit clunky. A nice treatment 
suggested by John Wickerson is the following: 



Wickerson's FOR-rule 

\- P^RtEj/V], h RAV>E 2 ^Q, h {R A V<E 2 } C {RIV+1/V1 } 
h {P} FOR V := E x UNTIL E 2 DO C {Q} 

where neither V, nor any variable occurring in E x or E 2 , is assigned to in 
the command C. 



Yet another alternative FOR-rule has been suggested by Bob Tennent: 



Tennent's FOR-rule 

h {PIV-l/V] A (£1 < V) A {V < E 2 )} C {P} 

h {PlEx-l/V^MEx-l^E^} FOR V := E l UNTIL E 2 DO C {P[E 2 /V]} 

where neither V, nor any variable occurring in E\ or E 2) is assigned to in 
the command C. 



This rule also has the property that the "special case" of executing the 
loop body 0 times can normally be handled without use of the FOR-axiom. 
Justify this claim. 

It is clear from the discussion above that there are various options for 
reasoning about FOR-commands in Floyd-Hoare logic. It may well be that 
one could argue for a 'best' approach (though, as far as I know, there is 
no consensus on this for our toy language, which is not surprising as FOR 
loops in real languages are more complex). The point is that designing 
rules for constructs that go beyond the simple core language of assignment, 
sequencing, conditionals and WHILE-loops is tricky and may involve personal 
preferences. 
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2.1.10 Arrays 

At the end of Section 2.1.1 it is shown that the naive array assignment axiom 

h {PIE 2 /A(E^} A(E 1 ):=E 2 {P} 

does not work, because of the possibility that changes to A(X) may also 
change A(Y), A(Z), . . . (since X might equal Y, Z, . . .). 

The solution, due to Hoare, is to treat an array assignment 

A(E 1 ):=E 2 

as an ordinary assignment 

A := A{E 1 <-E 2 } 

where the term A{Ei4—E 2 } denotes an array identical to A, except that the 
Ex-th component is changed to have the value E 2 . 

Thus an array assignment is just a special case of an ordinary variable 
assignment. 



The array assignment axiom 

h {P [A{E 1 <-E 2 }/A] } A(E 1 ) : =E 2 {P} 

Where A is an array variable, E\ is an integer valued expression, P is any 
statement and the notation A{E^E 2 } denotes the array identical to A, 
except that the value at E 1 is E 2 . 



In order to reason about arrays, the following axioms, which define the 
meaning of the notation A{E^E 2 }, are needed. 



The array axioms 

h AiE^E^E^ = E 2 

E 1 ^E 3 => h AiE^E^iEs) = A(E 3 ) 
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Example: We show 

h {A(X)=x A A(Y)=y} 
BEGIN 
VAR R; 

R := A(X); 
A(X) := A(Y); 
A(Y) := R 
END 

{A(X)=y A A(Y)=x} 

Working backwards using the array assignment axiom: 

h {A{Y^R}(X)=y A A{Y^R}(Y)=x} 
A(Y) := R 
{A(X)=y A A(Y)=x} 

By precondition strengthening using h A{Y-(— R} (Y) = R 

h {A{Y^R}(X)=y A R=x} 
A(Y) := R 
{A(X)=y A A(Y)=x} 

Continuing backwards 

h {A{X^A(Y)}{Y^R}(X)=y A R=x} 
A(X) := A(Y) 
{A{Y^R}(X)=y A R=x} 

h {A{X^A(Y)}{Y^A(X)}(X)=y A A(X)=x} 
R := A(X) 

{A{X^A(Y)}{Y^R}(X)=y A R=x} 

Hence by the derived sequencing rule: 

h {A{X^A(Y)}{Y^A(X)}(X)=y A A(X)=x} 
R := A(X); A(X) := A(Y) ; A(Y) := R 
{A(X)=y A A(Y)=x} 

By the array axioms (considering the cases X=Y and X^Y separately), it 
follows that: 

h A{X^A(Y)}{Y^A(X)}(X) = A(Y) 
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Hence: 

h {A(Y)=y A A(X)=x} 

R := A(X); A(X) := A(Y); A(Y) := R 
{A(X)=y A A(Y)=x} 

The desired result follows from the block rule. 

Example: Suppose C sort is a command that is intended to sort the first n 
elements of an array. To specify this formally, let SORTED (A, n) mean that: 

-4(1) < -4(2) < ... < A(n) 

A first attempt to specify that C sort sorts is: 

{1 < N} C sort {SORTED (A ,N)} 

This is not enough, however, because SORTED (A, N) can be achieved by simply 
zeroing the first N elements of A. 

It is necessary to require that the sorted array is a rearrangement, or permu- 
tation, of the original array. 

To formalize this, let PERM (A, A', AO mean that A(l), A(2), . . . , A(n) is a 
rearrangement of A' (1), A' (2), ... , A'(n). 

An improved specification that C sort sorts is then 

{1<N A A=a} C sort {SORTED (A, N) A PERM (A, a, N) } 
However, this still is not correct 

h {1<N A A=a} 
N:=l 

{SORTED (A ,N) A PERM (A, a, N)} 

It is necessary to say explicitly that N is unchanged also. A correct specifi- 
cation is thus: 

{1<N A A=a A N=n} C sm . t {SORTED (A, N) A PERM (A, a, N) A N=n} 
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Mechanizing Program 
Verification 



The architecture of a simple program verifier is described. Its 
operation is justified with respect to the rules of Hoare logic. 



After doing only a few examples, the following two things will be painfully 
clear: 

(i) Proofs are typically long and boring (even if the program being verified 
is quite simple). 

(ii) There are lots of fiddly little details to get right, many of which are 
trivial (e.g. proving h (R=X A Q=0) (X = R + YxQ)). 

Many attempts have been made (and are still being made) to automate 
proof of correctness by designing systems to do the boring and tricky bits of 
generating formal proofs in Hoare logic. Unfortunately logicians have shown 
that it is impossible in principle to design a decision procedure to decide 
automatically the truth or falsehood of an arbitrary mathematical statement 
[10]. However, this does not mean that one cannot have procedures that will 
prove many useful theorems. The non-existence of a general decision proce- 
dure merely shows that one cannot hope to prove everything automatically. 
In practice, it is quite possible to build a system that will mechanize many 
of the boring and routine aspects of verification. This chapter describes one 
commonly taken approach to doing this. 

Although it is impossible to decide automatically the truth or falsity of 
arbitrary statements, it is possible to check whether an arbitrary formal 
proof is valid. This consists in checking that the results occurring on each 
line of the proof are indeed either axioms or consequences of previous lines. 
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Since proofs of correctness of programs are typically very long and boring, 
they often contain mistakes when generated manually. It is thus useful to 
check proofs mechanically, even if they can only be generated with human 
assistance. 

3.1 Overview 

In the previous chapter it was shown how to prove {P}C{Q} by proving 
properties of the components of C and then putting these together (with the 
appropriate proof rule) to get the desired property of C itself. For example, 
to prove h {P}C i; C 2 {Q} first prove h {P}d{R} and h {R}C 2 {Q} (for 
suitable R), and then deduce h {P}C\ ; C 2 {Q} by the sequencing rule. 

This process is called forward proof because one moves forward from 
axioms via rules to conclusions. In practice, it is more natural to work back- 
wards: starting from the goal of showing {P}C{Q} one generates subgoals, 
subsubgoals etc. until the problem is solved. For example, suppose one wants 
to show: 

h {X=x A Y=y} R:=X; X:=Y; Y:=R {Y=x A X=y} 

then by the assignment axiom and sequencing rule it is sufficient to show the 
subgoal 

h {X=x A Y=y} R:=X; X:=Y {R=x A X=y} 

(because h {R=x A X=y} Y:=R {Y=x A X=y}). By a similar argument this 
subgoal can be reduced to 

h {X=x A Y=y} R:=X {R=x A Y=y} 

which clearly follows from the assignment axiom. 

This chapter describes how such a goal oriented method of proof can be 
formalised. 

The verification system described here can be viewed as a proof checker 
that also provides some help with generating proofs. The following diagram 
gives an overview of the system. 



3.1. Overview 
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Specification to be proved I 

1 » human expert 

Annotated specification ! 



vc generator 



Set of logic statements (VCs) 



theorem prover 



Simplified set of 
verification conditions 



1 » human expert 

End of proof 



The system takes as input a partial correctness specification annotated 
with mathematical statements describing relationships between variables. 
From the annotated specification the system generates a set of purely math- 
ematical statements, called verification conditions (or VCs). In Section 3.5 
it is shown that if these verification conditions are provable, then the original 
specification can be deduced from the axioms and rules of Hoare logic. 

The verification conditions are passed to a theorem prover program which 
attempts to prove them automatically; if it fails, advice is sought from the 
user. We will concentrate on those aspects pertaining to Hoare logic and say 
very little about theorem proving here. 

The aim of much current research is to build systems which reduce the 
role of the slow and expensive human expert to a minimum. This can be 
achieved by: 

• reducing the number and complexity of the annotations required, and 

• increasing the power of the theorem prover. 
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The next section explains how verification conditions work. In Section 3.5 
their use is justified in terms of the axioms and rules of Hoare logic. Besides 
being the basis for mechanical verification systems, verification conditions 
are a useful way of doing proofs by hand. 

3.2 Verification conditions 

The following sections describe how a goal oriented proof style can be for- 
malised. To prove a goal {P}C{Q}, three things must be done. These will 
be explained in detail later, but here is a quick overview: 

(i) The program C is annotated by inserting into it statements (often called 
assertions) expressing conditions that are meant to hold at various 
intermediate points. This step is tricky and needs intelligence and a 
good understanding of how the program works. Automating it is a 
problem of artificial intelligence. 

(ii) A set of logic statements called verification conditions (VCs for short) 
is then generated from the annotated specification. This process is 
purely mechanical and easily done by a program. 

(iii) The verification conditions are proved. Automating this is also a prob- 
lem of artificial intelligence. 

It will be shown that if one can prove all the verification conditions gen- 
erated from {P}C{Q} (where C is suitably annotated), then h {P}C{Q}. 

Since verification conditions are just mathematical statements, one can 
think of step 2 above as the 'compilation', or translation, of a verification 
problem into a conventional mathematical problem. 

The following example will give a preliminary feel for the use of verifica- 
tion conditions. 

Suppose the goal is to prove (see the example on page 26) 

m 

R:=X; 
Q:=0; 

WHILE Y<R DO (R:=R-Y; Q:=Q+1) 
{X = R+YxQ A R<Y} 



3.3. Annotation 
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This first step ((i) above) is to insert annotations. A suitable annotated 
specification is: 

m 

R:=X; 

Q:=0; {R=X A Q=0} < — P x 
WHILE Y<R DO {X = R+YxQ} < — P 2 
(R:=R-Y; Q:=Q+1) 
{X = R+YxQ A R<Y} 

The annotations Pi and P2 state conditions which are intended to hold when- 
ever control reaches them. Control only reaches the point at which Pi is 
placed once, but it reaches P 2 each time the WHILE body is executed and 
whenever this happens P 2 (i.e. X=R+YxQ) holds, even though the values of R 
and Q vary. P 2 is an invariant of the WHILE- command. 

The second step ((h) above), which has yet to be explained, will generate 
the following four verification conditions: 

(i) T (X=X A 0=0) 

(ii) (R=X A Q=0) (X = R+(YxQ)) 

(iii) (X = R+(YxQ)) A Y<R) (X = (R-Y) + (Yx (Q+l))) 

(iv) (X = R+(YxQ)) A -1 (Y<R) (X = R+(YxQ) A R<Y) 

Notice that these are statements of arithmetic; the constructs of our pro- 
gramming language have been 'compiled away'. 

The third step ((hi) above) consists in proving these four verification 
conditions. These are all well within the capabilities of modern automatic 
theorem provers. 

3.3 Annotation 

An annotated command is a command with statements (called assertions) 
embedded within it. A command is said to be properly annotated if state- 
ments have been inserted at the following places: 

(i) Before each command Ci (where i > 1) in a sequence C\ ; C 2 ; ... ;C n 
which is not an assignment command, 
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(ii) After the word DO in WHILE commands. 

Intuitively, the inserted assertions should express the conditions one expects 
to hold whenever control reaches the point at which the assertion occurs. 

A properly annotated specification is a specification {P}C{Q} where C 
is a properly annotated command. 

Example: To be properly annotated, assertions should be at points © and 
© of the specification below: 

{X=n} 

Y:=l; ^© 

WHILE X^O DO i — © 
(Y:=YxX; X:=X-1) 
{X=0 A Y=n!} 

Suitable statements would be: 

at ©: {Y = 1 A X = n} 
at ©: {YxX! = n!} 



The verification conditions generated from an annotated specification 
{P}C{Q} are described by considering the various possibilities for C in turn. 
This process is justified in Section 3.5 by showing that h {P}C{Q} if all the 
verification conditions can be proved. 

3.4 Verification condition generation 

In this section a procedure is described for generating verification conditions 
for an annotated partial correctness specification {P}C{Q}. This procedure 
is recursive on C. 



Assignment commands 

The single verification condition generated by 
{P}V:=E {Q} 

is 

P QIE/V] 
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Example: The verification condition for 

{X=0} X:=X+1 {X=l} 

is 

X=0 (X+l)=l 

(which is clearly true). 



Conditionals 

The verification conditions generated from 

{P} IF S THEN Ci ELSE C 2 {Q} 

arc 

(i) the verification conditions generated by 

{P A S} d {Q} 

(ii) the verification conditions generated by 

{P A ^S} C 2 {Q} 



If Ci ; . . . ; C n is properly annotated, then (see page 41) it must be of one 
of the two forms: 

1. Ci; ... ;C n ^;{R}C n , or 

2. Ci; ... ;C n -nV := E. 

where, in both cases, C\\ ... ; C„_i is a properly annotated command. 
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Sequences 

1. The verification conditions generated by 

{P} C i; ...;CU; {R}C n {Q} 
(where C n is not an assignment) are: 

(a) the verification conditions generated by 

{P} d ;...;<?„_! {R} 

(b) the verification conditions generated by 

{R} C n {Q} 

2. The verification conditions generated by 

{P} C 1 ;...;C n _ 1 ;V:=E {Q} 
are the verification conditions generated by 

{P} Ci; ... ;C n _! {QLE/V]} 



Example: The verification conditions generated from 

{X=x A Y=y} R:=X; X:=Y; Y:=R{X=y A Y=x} 
are those generated by 

{X=x A Y=y} R:=X; X:=Y { (X=y A Y=x) [R/Y] } 
which, after doing the substitution, simplifies to 

{X=x A Y=y} R:=X; X:=Y {X=y A R=x} 
The verification conditions generated by this are those generated by 

{X=x A Y=y} R:=X { (X=y A R=x) [Y/X] } 
which, after doing the substitution, simplifies to 
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{X=x A Y=y} R:=X {Y=y A R=x} . 
The only verification condition generated by this is 

X=x A Y=y (Y=y A R=x) [X/R] 
which, after doing the substitution, simplifies to 

X=x A Y=y =>■ Y=y A X=x 

which is obviously true. 

A correctly annotated specification of a WHILE-command has the form 
{P} WHILE S DO {R} C {Q} 
Following the usage on page 26, the annotation R is called an invariant. 

WHILE-commands 

The verification conditions generated from 

{P} WHILE S DO {R} C {Q} 

are 

(i) P R 

(ii) R A -iS =>• Q 

(iii) the verification conditions generated by {R A S} C{R}. 



Example: The verification conditions for 

{R=X A Q=0} 
WHILE Y<R DO {X=R+YxQ} 
(R:=R-Y; Q=Q+1) 
{X = R+(YxQ) A R<Y} 

are: 

(i) R=X A Q=0 (X = R+(YxQ)) 
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(ii) X = R+YxQ A -> (Y<R) (X = R+(YxQ) A R<Y) 

together with the verification condition for 

{X = R+(YxQ) A (Y<R) } 

(R:=R-Y; Q:=Q+1) 
{X=R+(YxQ)} 

which consists of the single condition 

(iii) X = R+(YxQ) A (Y<R) X = (R-Y) + (Yx (Q+l) ) 

The WHILE-command specification is thus true if (i), (ii) and (iii) hold, i.e. 

h {R=X A Q=0} 
WHILE Y<R DO 

(R:=R-Y; Q:=Q+1) 

{X = R+(YxQ) A R<Y} 

if 

h R=X A Q=0 (X = R+(YxQ)) 

and 

h X = R+(YxQ) A -i (Y<R) =>■ (X = R+(YxQ) A R<Y) 

and 

h X = R+(YxQ) A (Y<R) X = (R-Y) + (Yx (Q+l) ) 



3.5 Justification of verification conditions 

It will be shown in this section that an annotated specification {P}C{Q} 
is provable in Hoare logic (i.e. h {P}C{Q}) if the verification conditions 
generated by it are provable. This shows that the verification conditions are 
sufficient, but not that they are necessary. In fact, the verification conditions 
are the weakest sufficient conditions, but we will neither make this more 
precise nor go into details here. An in-depth study of preconditions can be 
found in Dijkstra's book [8]. 

It is easy to show that the verification conditions are not necessary, i.e. 
that the verification conditions for {P}C{Q} not being provable doesn't 
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imply that h {P}C{Q} cannot be deduced. For example, the verification 
conditions from the annotated specification {T} WHILE F DO {F} X:=0 {T} 
are not provable, but this Hoare triple is provable in Hoare logic. 

The argument that the verification conditions are sufficient will be by 
induction on the structure of C. Such inductive arguments have two parts. 
First, it is shown that the result holds for assignment commands. Second, it 
is shown that when C is not an assignment command, then if the result holds 
for the constituent commands of C (this is called the induction hypothesis), 
then it holds also for C. The first of these parts is called the basis of the 
induction and the second is called the step. From the basis and the step it 
follows that the result holds for all commands. 

Assignments 

The only verification condition for {P}V:=E{Q} is P =>• QIE/V]. If this 
is provable, then as h {Q IE/V~i }V:=E{Q} (by the assignment axiom on 
page 20) it follows by precondition strengthening (page 22) that h {P}V : = 
E{Q}. 

Conditionals 

If the verification conditions for {P} IF S THEN d ELSE C 2 {Q} are prov- 
able, then the verification conditions for both {P A S} C\ {Q} and 
{P A ->S} C 2 {Q} are provable. By the induction hypothesis we can assume 
that h {P A S} Ci {Q} and h {P A ~^S} C 2 {Q}. Hence by the 
conditional rule (page 26) h {P} IF S THEN d ELSE C 2 {Q}- 

Sequences 

There are two cases to consider: 

(i) If the verification conditions for {P} C\ \ ... ;C n -i ; {R}C n {Q} are 
provable, then the verification conditions for {P} C\ ; . . . ; C n _i {R} 
and {R} C n {Q} must both be provable and hence by induction we 
have h {P} d; . . . {R} and h {R} C n {Q}. Hence by the 
sequencing rule (page 24) h {P} d; ... ; d-ilC n {Q}. 

(ii) If the verification conditions for {P} Ci; ... ;C n -i;V := E {Q} are 
provable, then it must be the case that the verification conditions for 
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{P} C\ ; . . . ; C„_i {Q IE /VI } are also provable and hence by induction 
we have h {P} d; ... ;C n _ x {QIE/V]}. It then follows by the 
assignment axiom that h {Q[E/V]} V := E {Q}, hence by the 
sequencing rule h {P} d ; . . . ; C n -i ; V := E{Q}. 

WHILE-commands 

If the verification conditions for {P} WHILE S DO {R} C {Q} are provable, 
then h P R, h (R A ->S) Q and the verification conditions for 
{R A S} C {R} are provable. By induction h {R A S} C {R}, hence by 
the WHILE-rule (page 26) h {R} WHILE S DO C {R A ^5}, hence by the 
consequence rules (see page 24) h {P} WHILE S" DO C {Q}. 



Chapter 4 



Soundness and Completeness 



The question of whether the axioms and rules of Hoare logic are 
correct (soundness) and sufficient (completeness) is investigated. 
This requires the meaning (semantics) of the programming lan- 
guage to be formulated explicitly so that the semantics of Hoare 
triples can be rigorously defined. 



4.1 Semantics 

A command C transforms an initial state into a final state (or fails to ter- 
minate). For the language described so far there is at most one final state 
reachable from a given initial state - i.e. commands are deterministic - but 
this will not be the case later, when we add storage allocation to our lan- 
guage. There are several essentially equivalent ways to represent the meaning 
of commands mathematically. We will use relations, but partial functions are 
often used. Use of relations is associated with operational semantics and par- 
tial functions with denotational semantics, however this is not rigid: denota- 
tional semantics can use relations as denotations and operational semantics 
can inductively define functions. In fact, in Section 4.1.2 below, we give a 
denotational semantics of commands in which the denotations are relations. 

The various styles of semantics are largely just different ways of repre- 
senting the same mathematical ideas. Some mathematical representations 
are better suited for some purposes and other representations for others. 
The semantics I give below may or may not correspond to semantics you 
have seen before in earlier courses. If it seems different, then a good exercise 
is to think about how it is related. 

We are going to represent the meaning of a command C by a binary 
relation on the set of states: s\ is related to S2 in this relation iff when C is 
executed in state s\ it terminates in state s 2 . 
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There are several ways of representing relations mathematically and al- 
though it doesn't really matter which one is chosen, it may help avoid confu- 
sion in what follows if we say a little about these alternative representations 
here, before diving into specific details. 

Introductory books on set theory usually represent relations as sets of 
ordered pairs, so x is related to y by relation R iff (x, y) G R. Thus a binary 
relation R between sets X and Y is a subset of X x Y, i.e. R C (X x Y) or, 
equivalently, R G V(X x Y), where V is the powerset operator. If S is any set 
then any subset ACS can be characterised by a function f A :S—> {T, F} 
defined by: 

Vs G S. f A (s) = T <S> s G A 

f a is called the characteristic junction of A. Thus a relation i? C (X x Y) 
can be characterised by its characteristic function f R defined by: 

eX.Vye Y. f R (x,y) = T & (x, y) G R 

where f R : (X x Y) — y {T, F}. If the set of functions from set S to set T is 
denoted by (S ->■ T) and Booi is the set {T, F}, then f R G ((X x Y) ->■ Bool). 
You may recall from earlier courses (e.g. on ML) that functions that take two 
or more arguments can be 'curried' so that they take the arguments one at 
a time. If we curry f R we get a function f ( R urr%ed defined by: 

f^ned X y = f R (x,y) 

and then /™ ed : X ->• (Y ->■ Bool) or : X ->■ Y ->■ Booi if we 

assume the standard convention that — > associates to the right. Note that 
we also have f c R urried G V(X -+ Y -+ Bool). 

To sum up, a relation R can be represented by a set of pairs, by a charac- 
teristic function that maps pairs to Booleans, or by the curried characteristic 
function. For a somewhat arbitrary mixture of historical and stylistic rea- 
sons, we are going to use the curried characteristic function representation of 
relations to represent the semantics of commands. Specifically, we are going 
to define Csem C S\ s 2 to mean that if command C is started in state si 
then it can terminate in state s 2 . Here Csem C is the relation that represents 
the semantics of C, represented as a curried characteristic function. The 
set of commands in our language will be denoted by Com and the set of 
states will be denoted by State. Thus Csem C : State -y State -y Bool or 
Csem : Com -y State ->• State -y Bool. As mentioned earlier, the choice of 
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representing Csem C as a curried characteristic function, rather than as a set 
of ordered pairs, is more a matter of style than substance. 

Let Var be the set of variables that are allowed in statements, expressions 
and commands and Val be the set of values that variables can take. It is not 
necessary to be specific about what variables and values actually are: Var 
could be, for example, the set of finite strings of ASCII characters and Val 
could be the set of integers. A state determines the value of each variable 
and, in addition, may contain other information. For our little programming 
language it is sufficient to take the state to be a function from Var to Val. 
Using the notation A B to denote the set of functions with domain A and 
range (codomain) B we define the set State of states by: 

State = Var Val 

Note that the following are all equivalent s G State, s G (Var — > Val) and 
s : Var — > Val. I will sometimes use s(v ) and sometimes s v for the value 
associated with variable v in state s (i.e. the application of the function 
representing the state s to v). Although in this chapter it is sufficient to 
represent states as functions from variables to values, in Chapter 7 we will 
need to add another components to the state to represents the contents of 
pointers. We will extend the definition of State in that chapter. Particular 
states can be defined using A-notation. For example, the state that maps X 
to 1, Y to 2 and everything else to 0 is defined by: 

Xv . ifv=X then 1 else (ifv=Y then 2 else 0) 

If s G State, v G Var and n G Val then s[n/v] denotes that state that is 
the same as s, except for the value of variable v is 'updated' to be n. Thus 
sln/vl is given by the equation: 

s [n/v] = Xv ' . ifv' = v then n else s(v') (where v' is a new variable) 
Example: 

(\v. if v =X then 1 else (ifv=Y then 2 else 0)) [3/Z] = 
Xv. ifv=X then 1 else (ifv=Y then 2 else (ifv=Z then 3 else 0)) 

4.1.1 Semantics of expressions and statements 

Commands may contain expressions or statements: expressions occur on the 
right hand side of assignments and statements occur in the tests of condi- 
tionals and WHILE- commands. The precondition and postcondition of Hoare 
triples are also statements. The classical treatment of Hoare logic was built 
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upon first order logic, expressions were taken to be terms of logic and state- 
ments to be formulae. You will be familiar with the semantics of first order 
logic from earlier courses and I do not want to repeat that material here. 
Furthermore, in modern applications, the language used for writing precon- 
ditions and postconditions is now sometimes weaker or stronger than first 
order logic, e.g. quantifier free logic (weaker) or higher order logic (stronger). 

To avoid the details of particular logics and their semantics we will assume 
that we are given sets Exp and Sta of expressions and statements, together 
with semantic functions Esem and Ssem defining their semantics, where: 

Esem : Exp -y State —y Val 
Ssem : Sta — y State — y Bool 

We now give some informal discussion and examples to illustrate how Esem 
and Ssem might be defined for particular logics (i.e. for particular Exp and 
Sta) . We hope it will be clear from this how a more formal treatment would 
go. In the usual logic terminology (e.g. as used in the IB Tripos course Logic 
and Proof) we are using states to represent interpretation functions and Val 
as the domain or universe. Variables are interpreted by looking them up in 
the state: 

Esem X s = s(X) 

Constants get their usual mathematical or logical meaning: 

Esem 3 s = 3 
Ssem T s = T 

Compound expressions or statements are interpreted bottom up: the (re- 
cursively computed) value of sub-expressions is combined using appropriate 
mathematical or logical operators to get the interpretation of the whole ex- 
pression. For example: 

Esem (-E) s = -(Esem E s) 

Esem (E 1 + E 2 ) s = (Esem E x s) + (Esem E 2 s) 

Ssem (->S) s = -i(Ssem S s) 

Ssem (Si < S 2 ) s = (Ssem Si s) < (Ssem S 2 s) 

where the symbols "— ", "+", "-i" and "<" on the left hand side of these 
equations are part of the syntax of statements (i.e. part of the object lan- 
guage) and those on the right hand side are informal mathematical notation 
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(i.e. part of our metalanguage). This is a subtle point worth pondering! 
Quantifiers (which may occur in preconditions and postconditions, but prob- 
ably not in tests in commands) are interpreted in the standard way: 

Ssem (Wv. S) s = Wn Ssem S (sbi/vl) 
Ssem (3v. S) s = 3n. Ssem S (sin/v]) 

Example: 

Ssem (Y<Z+3) {\v. ifv=X then 1 else (ifv=Y then 2 else 0)) = (2<0+3) 

I hope this is sufficient explanation of Esem and Ssem for what follows. Note 
that for any E G Exp and S G St a it is the case that: 

Esem E : State ->■ Val 
Ssem S : State — > Bool 

4.1.2 Semantics of commands 

Csem C si s 2 will be defined recursively bottom up. The only commands 
that don't contain sub-commands are assignments. After an assignment the 
final state s 2 is equal to the initial state with the variable V on the left hand 
side of the assignment updated to have the value of the expression E on the 
right hand side of the assignment in the initial state. 

| Csem (V:=E) Sl s 2 = (s 2 = si [(Esem E s^/VI) \ 

A final state s 2 can be reached by executing a sequence C\ ; C 2 starting in 
an initial state s± iff there is an intermediate state s reachable by executing 
Ci in si and s 2 is reachable from this intermediate state by executing C 2 . 

| Csem {Ci;C 2 ) s\ s 2 = 3s. Csem C\ ~s\ s A Csem C 2 s s 2 | 

If S is true in a state S\ then state s 2 can be reached by executing the 
conditional IF S THEN C\ ELSE C 2 starting in si iff s 2 can be reached by ex- 
ecuting the THEN-branch C\ starting in s\. However, if S is false in a state 
Si then state s 2 can be reached by executing conditional starting in si iff s 2 
can be reached by executing the ELSE-branch C 2 starting in Si. 

Csem (IF S THEN C x ELSE C 2 ) s x s 2 = 

if Ssem S s 1 then Csem d s 1 s 2 else Csem C 2 si s 2 
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If final state s 2 can be reached from initial state si by executing 
WHILE S DO C, then there must be some finite number of iterations of C that 
will reach s 2 , S must be true in all the intermediate states and false in s 2 . 
This is formalised by defining a function Iter that iterates a finite number of 
times and then defining: 

| Csem (WHILE S DO C) si s 2 = Bn. Iter n (Ssem S) (Csem C) s 1 s 2 |j 

The function Iter is defined by recursion on n as follows: 

Iter 0 p c si s 2 = ->(p si) A (s 1 =s 2 ) 

Iter (n+1) p c Si s 2 = p s± A 3s. c si s A Iter n p c s s 2 

The first argument ra of Iter is the number of iterations. The second argument 
p is a predicate on states (e.g. Ssem S). The third argument c is a curried 
characteristic function (e.g. Csem C). The fourth and fifth arguments are 
the initial and final states, respectively. If Num. is the set of natural numbers 
{0,1,2,...}, then: 

Iter : IVum-> (Stated Bool) ->• (State-* State-* Bool) -> Stated Stated Bool 

4.2 Soundness of Hoare logic 

The meaning of a Hoare triple {P} C {Q} is defined to be Hsem P C Q 
where: 

| Hsem P C Q = Vsi s 2 - Ssem P si A Csem C gi s 2 =^> Ssem Q g 2 | 

This definition can be used to formulate the soundness of Hoare logic. To do 
this we must prove that all instances of the assignment axiom are true, and 
that all conclusions deduced using inference rules are true if the hypotheses 
are true. Recall the assignment axiom: 



The assignment axiom 

h {P[E /VI} V:=E {P} 

Where V is any variable, E is any expression, P is any statement and 
the notation P[E/V~\ denotes the result of substituting the term E for 
all occurrences of the variable V in the statement P. 
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To prove this sound we must show that for every V, E and P: 

Hsem (P[E/V~\) (V:=E) P 
Unfolding the definition of Hsem converts this to: 

Vsi s 2 . Ssem [PIE/V] ) si A Csem (V :=E) Sl s 2 Ssem P s 2 
Unfolding the definition of Csem converts this to: 

Vsi s 2 . Ssem (PIE/V] ) si A (s 2 = si [(Esem E s^/V]) Ssem P s 2 
which simplifies to: 

Vsi. Ssem (P[E/V\) Sl => Ssem P ( Sl [(Esem £ si)/U]) 

This may appear confusing since it uses the notation [•••/•••] with dif- 
ferent meanings in the antecedent (the left argument of =>•) and consequent 
(the right argument). In the antecedent, P[E/V~\ denotes the result of sub- 
stituting the expression E for the variable V in the statement P. In the 
consequent Si [(Esem E s^/V] denotes the state obtained by updating si 
so that the value of V is the value of E in si (and the values of all other 
variables are unchanged). 

Diversion on substitution. 

We have avoided specifying in detail exactly what the syntax of expressions 
and statements is, so it is not possible to prove general properties about 
them. However, for any reasonable definitions we would expect that: 

Ssem {PIE/V]) s = Ssem P (s[(Esem E s)/V]) 

For example, take P to be X+Y>Z, E to be X+l and V to be Y, then the 
equation above becomes: 

Ssem ((X+Y>Z)[(X+1)/Y]) s = Ssem (X+Y>Z) (s[(Esem (X+l) s)/Y]) 
Now Esem (X+l) s = s(X)+l so the equation above becomes: 

Ssem ((X+Y>Z)[(X+1)/Y]) s = Ssem (X+Y>Z) (s[(s(X)+l)/Y]) 
Evaluating the substitution on the left hand side reduces this to: 

Ssem (X+(X+1)>Z) s = Ssem (X+Y>Z) (s [(s(X)+l)/Y] ) 

Evaluating the Ssem gives: 

(a(X)+(a(X)+l)> a (Z)) = 

((s[(s(X)+l)/Y])(X)+(s[(s(X)+l)/Y])(Y)>(s[(s(X)+l)/Y])(Z)) 
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Using the definition of s [n/v] , and assuming X, Y and Z are distinct, enables 
the right hand side of this equation to be simplified, to give: 

(s(X)+(s(X)+l)>s(Z)) = (s(X)+(s(X)+l)>s(Z)) 

This is clearly true as the left and right hand sides are identical. 

Although this is just an example, it illustrates why for all S, E, V and s 
it is the case that: Ssem (S\_E/V~\) s = Ssem S (s[(Esem E s)/V~\) 

In fact, if this equation did not hold then one would have a bad defi- 
nition of substitution - indeed this equation can be taken as the semantic 
specification of substitution! 
End of diversion on substitution. 

Returning to the soundness of the assignment axiom, recall that it was 
equivalent to the following holding for all P, E and V: 

Vsi. Ssem (P[E/V1) s 1 Ssem P ( Sl [(Esem E s^/Vl) 

If the equation for substitution motivated in the diversion above holds, then 
this implication holds too, since for any statements P and Q, if P = Q then 
it follows that P =>• Q. 

Thus, assuming the semantic substitution equation discussed above, we have 
shown that the assignment axiom is sound. 

The soundness of the Hoare logic rules of inference is almost trivial except 
for the WHILE-rule, and even that is fairly straightforward. We will restate 
the rules and then outline the proof of their soundness. 

Precondition strengthening 

h P =» P', h {P'} C {Q} 

i- m c {Q} 

This rule is sound if the following is true for all P, P', C and Q: 
(Vs. Ssem P Ssem P' s) A Hsem P' C Q Hsem P C Q 
which, after expanding the definition of Hsem, becomes: 

(Vs. Ssem P s Ssem P' s) A 

(Vsi s 2 . Ssem P' s 1 A Csem C s x s 2 =^ Ssem Q s 2 ) 

Vsi s 2 . Ssem P si A Csem C Si s 2 ^> Ssem Q s 2 
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This is an instance of the statement below if we take p, p', q, c to be Ssem P, 
Ssem P', Ssem Q, Csem C, respectively. 

(Vs. ps^p's) A (Vsi s 2 . p' Si A c Si s 2 =>• 9 s 2 ) 

Vsi s 2 . p si A c si s 2 =>• 9 s 2 
This is clearly true. 

Postcondition weakening 

h {P}C{Q>}, h Q'^Q 
H W C {Q} 

This is sound by a similar argument. 

Specification conjunction 

h {P 1 } C {Q 1 }, h {P 2 } C {Q 2 } 
h {Px A P 2 } C {Qi A Q 2 } 

Specification disjunction 

h {PJ C {Q 1 }, h {P 2 } g {Q 2 } 

h {PiVP.jciQivg,} 

This is sound by a similar argument. 

The sequencing rule 

h {P} Ci {Q}, h {Q} C 2 {P} 
I- {P}C i; C 2 {P} 



This rule is sound if the following is true for all P, Q, R, C\ and C 2 : 
Hsem P d Q A Hsem Q C 2 R ^ Hsem P (C i; C 2 ) P 
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which, after expanding the definition of Hsem, becomes: 

fVsi s 2 . Ssem ? si A Csem C Si s 2 =>• Ssem Q s 2 ) A 
(Vsi s 2 . Ssem Q si A Csem C si s 2 =>- Ssem R s 2 ) 

=>• 

Vsi s 2 . Ssem P si A Csem (Ci;C 2 ) si s 2 =>• Ssem R s 2 
This is an instance of the statement below if we unfold the definition of 
Csem (Ci;C 2 ) and take p, q, r, ci, c 2 to be Ssem P, Ssem Q, Ssem P, 
Csem Ci, Csem C 2 , respectively. 

(Vsi s 2 . p S\ f\ C\ S\ s 2 q s 2 ) A (Vsi s 2 . g Si A c 2 Si s 2 =>- r s 2 ) 

Vsi s 2 . p s\ A (3s. ci si s A c 2 s s 2 ) =>- r s 2 
This is clearly true. 

The conditional rule 

h {pas} Ci {Q}, h {pa -^s} c 2 {Q} 

h {P} IF S THEN Ci ELSE C 2 {Q} 



A similar argument to the one for the sequencing rule shows the conditional 
rule to be sound. 



The WHILE-rule 

h {PAS} C {P} 
h {P} WHILE S DO C {P A -^S} 



This rule is sound if the following is true for all P, S and C: 
Hsem (P A S) C P =$> Hsem P (WHILE S DO C) (P A -5)) 
which, after expanding the definition of Hsem, becomes: 
(Vsi s 2 . Ssem (P A 5) si A Csem C s 1 s 2 ^ Ssem P s 2 ) 
Vsi s 2 . Ssem P s x A Csem (WHILE S DO C) s 2 s 2 => Ssem (P A -.5) s 2 
Using the equations Ssem (P A Q) Si = Ssem P s x A Ssem Q Si and 
Ssem (P A -iQ) s 2 = Ssem P s 2 A ->(Ssem Q si) and expanding the defi- 
nition of Hsem (WHILE S DO C) converts this to: 
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(Vsi s 2 . Ssem ? si A Ssem S si A Csem C si s 2 =>• Ssem P si 

=► 

Vsi s 2 . Ssem P si A (3n. Iter n (Ssem 5) (Csem C) si s 2 ) 
Ssem P s 2 A -i(Ssem 5 s 2 ) 
This is an instance of the statement below if we take p, b, c to be Ssem P, 
Ssem S, Csem C, respectively. 

(Vsi s 2 . p si A & si A c si s 2 =>- p si) 
=>• 

Vsi s 2 . psiA (3n. Iter n k si s 2 ) =^ p s 2 A s 2 ) 

which is equivalent to: 

(Vsi s 2 . p Si A 6 si A c si s 2 =>• p Si) 
=> 

Vn si s 2 . p si A Iter n 6 c si s 2 =>■ p s 2 A s 2 ) 
To prove this, assume the antecedent and show the consequent by induction 
of n. The basis (n = 0 case) is clearly true as 'false implies everything'. For 
the induction step assume: 

1. Vsi s 2 . p si A 6 si A c si s 2 =^ p Si (Hoare rule hypothesis) 

2. Vsi s 2 . p si A Iter nb c s\ s 2 => p s 2 A ->(& s 2 ) (induction hypothesis) 
From these we must show the induction conclusion: 

p si A Iter (n+1) 6 c si s 2 =^ p s 2 A s 2 ) 
Using the recursive definition of Iter (n+1) converts this to: 

p si A (b s 1 A 3s. c «i s A Iter n b c s s 2 ) =>• p s 2 A s 2 ) 
which with a bit of quantifier fiddling is equivalent to: 

p si A 6 si A c si s A Iter nbcss 2 =>ps 2 A ->(b s 2 ) 

Which follows from the Hoare rule hypothesis and the induction hypothesis 
(i.e. 1 and 2 above) by a bit of implication chaining. 

4.3 Decidability and completeness 

{T}C{F} is true if and only if C does not terminate, therefore, since the 
halting problem is undecidable, so is Hoare logic. 

Soundness is that any Hoare triple that can be deduced using the ax- 
ioms and rules of inference of Hoare logic is true. The converse, complete- 
ness, would be that any true Hoare triple could be deduced using the ax- 
ioms and rules of Hoare logic. Unfortunately, this cannot hold in general. 
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Consider {T} X:=X{P}. According to the semantics above, this is true iff 
Hsem T (X:=X) P is true, i.e.: 

Vsi s 2 . Ssem T s 1 A Csem (X:=X) s 1 s 2 Ssem P s 2 

Since Csem (X:=X) Si s 2 = ($2 = Si) and Ssem T s x = T this reduces to: 

Vsi s 2 . T A (s 2 = Si) =>- Ssem P s 2 

which, by specialising s± and s 2 to s, simplifies to Vs. Ssem P s - i.e. P 
is true. Thus if we could deduce any true Hoare triple using Hoare logic 
then we would be able to deduce any true statement of the specification 
language using Hoare logic! Most logics suitable for specifying programs are 
incomplete (e.g. first order arithmetic), so Hoare logic cannot be complete. 

However the kind of completeness just described above is only impossible 
due to the incompleteness of the specification language used for precondi- 
tions and postconditions. If we separate the 'programming logic' from the 
'specification logic', then it is possible to formulate a sort of completeness, 
called relative completeness [6], that provides some reassurance that Hoare 
logic is adequate for reasoning about the small collection of simple commands 
we have discussed - i.e. there are no 'missing' axioms or rules. It turns out, 
however, that even this limited kind of completeness may be impossible for 
constructs found in many real languages (but not in our 'toy' language) [5] . 

We will not attempt to explain the exact details of Cook's and others' 
work on relative completeness, as both the technical logical issues and also 
their intuitive interpretation are quite subtle [1, 16]. Furthermore doing this 
would require us to be more precise than we wish about the syntax, seman- 
tics and proof theory of the specification language in which preconditions and 
postconditions are expressed. We will, however, sketch the key ideas. A con- 
cept that is used in proving relative completeness is the weakest precondition. 
This concept is not only useful for its role in showing relative completeness, 
it also has practical applications, including providing an improved approach 
to verification conditions (which we discuss later) and as the foundation for 
theories of program refinement. 

4.3.1 Relative completeness 

We are going to explain the idea of relative completeness and also show 
that it holds for our little programming language by using weakest liberal 
preconditions. However, we will put off the detailed definition and analysis 
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of these until Section 4.3.2. In this section we say just enough about what 
they are and what properties they have (P l5 P 2 and P 3 below) so that we 
can explain relative completeness. 

For each command C and statement Q we assume there is a statement 
wlp(C,Q) - intuitively the weakest precondition such that ensures Q holds 
after executing C - with the property that: 

h {wip(c ) g)}c{g} (PO 

The existence of the statement wlp(C ,Q) in the specification language de- 
pends on the specification language being strong enough. A language strong 
enough to enable wlp(C ,Q) to be defined is called expressive. 

The operator wlp constructs a statement, which is a sentence in a formal 
language, from a command and another statement. Thus wlp constructs a 
syntactic thing (a statement) from other syntactic things (a command and 
a statement). We also assume a semantic counterpart to wlp called Wlp 
which operates on the meanings of commands (functions representing binary 
relations on states) and the meanings of statements (predicates on states). 
Wlp is a curried function: 

Wlp : (State -> State ->■ Bool) ->■ (State ->■ Bool) ->■ State ->■ Bool 

we assume the following property connecting wlp and Wlp for all commands 
C and statements Q: 

Ssem (wlp(CQ)) = Wlp (Csem C)(Ssem Q) (P 2 ) 

Notice that this is an equation between predicates. We also assume: 

Hsem P C Q = Vs. Ssem P s => Wlp (Csem C) (Ssem Q) s (P 3 ) 

The shape of the relative completeness proof can now be sketched. As- 
sume {P} C {Q} is true, i.e. Hsem P C Q is true. We will show that the 
statement P =>■ wlp(C,Q) must also be true - assume this for now. If we 
could prove this true statement, i.e. had h P =>- wlp (C ,Q), then by precon- 
dition strengthening and the property Pi it would follow that h {P} C {Q} 
by Hoare logic. Thus Hoare logic is complete relative to the existence of an 
oracle for proving any true statement of the form P wlpCC.Q)- 

To summarise: relative completeness says that if wlp(C,Q) is expressible 
in the specification language and if there is an oracle to prove true statements 
of the form P =^ wlp(C,<5), then any true Hoare triple {P} C {Q} can be 
proved using Hoare logic. 
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We now run through the relative completeness argument again, but in a 
bit more detail, showing how assumptions P 2 and P 3 are used. Recall: 

Ssem (wlp(C,Q)) = Wlp (Csem C)(Ssem Q) (P 2 ) 

Hsem P C Q = Vs. Ssem P s Wlp (Csem C) (Ssem Q) s (P 3 ) 
Assume for any C and Q that wlp(C,<5) is expressible in the specification 
language and also that for any P, C and Q there is an oracle to prove true 
statements of the form P =>- wlp(C,<5) - i.e. if Vs. Ssem (P =>- wlp(C,Q)) s 
(statement true) then the oracle gives h?=^> wlp(C ,Q) (statement proved). 

The Hoare triple {P} C {Q} being true means, according to our seman- 
tics, that Hsem P C Q is true. If this is true, then by P 3 assumed above: 

Vs. Ssem P s ^ Wlp (Csem C) (Ssem Q) s 

and then by assumed property P 2 : 

Vs. Ssem P s Ssem (wlp(C.Q)) s 

Although we have not completely defined the specification language, we as- 
sume at least that it contains an infix symbol =>• whose meaning is logical 
implication, so that from the statement above we can deduce: 

Vs. Ssem (P^wlp(C,Q)) s 

i.e. the statement P =>■ wlp(C,Q) is true. Now we use the assumed oracle 
for formulae of this form to prove h P =>- wlp(C,<5) and hence by assumed 
property Pi and precondition strengthening, we can prove h {P} C {Q}. 

To complete the outline above we must define wlp and Wlp and prove 
the properties Pi, P 2 and P 3 . The axioms and rules of Hoare logic will be 
used to prove Pi, and it is the fact that they can prove this that is really the 
essence of their completeness. 

4.3.2 Syntactic and semantic weakest preconditions 

If P =^ Q we say that P is stronger than Q and, dually, that Q is weaker 
than P. The weakest precondition of a command C with respect to a 
postcondition Q is the weakest predicate, denoted by wp(C,<5), such that 
[wp(C,Q)] C [Q] . Notice that this is related to total correctness. The 
partial correctness concept is called the weakest liberal precondition and is 
denoted by wlp(C ,Q): the statement wlp(C ,Q) is the weakest predicate 
such that {wlp(C ,Q)} C {Q}. In this chapter we only use weakest liberal 
preconditions. Their key properties are Pi, i.e. h {wlp(C,Q)} C {Q} and 
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for all P that {P} C {Q} (P =>• wlp(C.Q)). These properties can be 
expressed more concisely as the single equation: 

{P}C{Q} = (P^wlp(C,Q)) 

This equation is easily seen to be equivalent to the key properties just men- 
tioned using the rule of precondition strengthening and the reflexivity of =^. 

If the specification language - i.e. the language of preconditions and post- 
conditions - is strong enough to express the weakest liberal precondition for 
all commands C and postconditions Q then it is said to be expressive. Since 
we haven't said what the specification language is we cannot say much about 
expressiveness. 

We can define the semantic operator Wlp on predicates via our semantics; 
this is an example of a predicate transformer [7] . 

Wlp c q = As. Vs'. c s s' =>- q s' 
Recall the definition of Hsem: 

Hsem P C Q = Vsi s 2 . Ssem P si A Csem C si s 2 =>- Ssem Q s 2 
We can easily prove property P 3 , namely: 

Hsem P C Q = Vs. Ssem P s =>• Wlp (Csem P) (Ssem Q) s 

P 3 follows from the definitions of Hsem and Wlp by taking p, c and q to be 
Ssem P, Csem C and Ssem Q, respectively, in the logical truth below. 

(Vsi s 2 . p Si A c Si s 2 =>- q s 2 ) = (Vs. p s ^ (As. Vs'. c s s' =>■ g s') s) 

To prove Pi and P 2 we need the following equations, which follow from the 
definition of Wlp. 

Wlp (Csem(y :=£)) g 

= As. g(s[(Esem ,B s)/V]) 

Wlp (Csem(Ci;C 2 )) g 

= As. Wlp (Csem d) (Wlp (Csem C 2 ) g) s 

Wlp (Csem(lF 5 THEN Ci ELSE C 2 )) g 

= As. z/Ssem S* s i/ien Wlp (Csem Ci) q s else Wlp (Csem C 2 ) q s 

Wlp (Cserr^WHILESDO C)) q 

= As. Vn. IterWIp n (Ssem 5) (Csem C) g s 
where IterWIp 0 p c g s = s) =>• g s 

IterWIp (n+1) p c q s = p s =>• Wlp c (IterWIp n p c q) s 
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We prove the equation for WHILE- commands. Expanding the definitions of 
Wlp and Csem yields: 

(As. W. (3n. Iter n (Ssem S) (Csem C) s s') s s' q s') 
= As. Vn. IterWIp n (Ssem S) (Csem C) q s 
Thus it is sufficient to prove that: 

Vs. (Vn s'. Iter n p c s s' q s') = Vn. IterWIp n p c q s 
which follows from: 

Vn s. (Vs'. Iter n p c s s' q s') = IterWIp n p c q s 
which is equivalent to: 

Vn s. Wlp (Iter n p c) q s = IterWIp n p c q s 
We prove this by induction on n. First recall the definitions: 

Iter 0 p c si s 2 = si) A (si=s 2 ) 

Iter (n+1) p c Si s 2 = p Si A 3s. c s x s A Iter n p c s s 2 

IterWIp 0 p c q = As. -i(p s)^gs 

IterWIp (n+1) peg = As. p s =>- Wlp c (IterWIp n p c q) s 

Basis. 

The n = 0 case is Wlp (Iter 0 p c) q s = IterWIp 0 p c q s which unfolds to 

(Vs'. -i(p s) A (s = s') ^ g s') = s) =>• g s which is true. 

Step. 

The induction hypothesis is Vs. Wlp (Iter n p c) q s = IterWIp n p c q s. 
From this we must show Wlp (Iter (n+1) p c) q s = IterWIp (n+1) p c q s. 
This unfolds to: 

Wlp (As x s 2 . p si A 3s. c Si s A Iter n p c s s 2 ) q s 

— p s =>• Wlp c (IterWIp n p c q) s 
Unfolding Wlp turns this into: 

(As. Vs'. (Asi s 2 . p si A 3s. c si s A Iter n p c s s 2 ) s s' =^ g s') s 
= p s =>- (As. Vs'. css'=> (IterWIp n p c q) s') s 
which reduces to: 

(Vs'. p s A (3s". ess" A Iter n p c s" s') =^ g s') 
= ps 4 Vs". c s s" 4 IterWIp n p c q s" 
Using the induction hypothesis on the RHS converts this to: 
(Vs'. p s A (3s". ess" A Iter n p c s" s') =^ q s') 

— p s Vs". c s s" =>- Wlp (Iter n p c) q s" 
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Unfolding Wlp: 

(Vs'. p s A (3s". ess" A Iter n p c s" s') =>• q s') 
= p s =>- Vs". c s s" 4 (As. Vs'. (Iter n p c) s s' q s') s" 

which reduces to: 

(Vs'. p s A (3s". ess" A Iter n p c s" s') =>- g s') 
= p s =>• Vs". c s s" =>- Vs'. Iter n p c s" s' =$> q s' 

which is true via a bit of quantifier manipulation. Thus we have proved: 

Wlp (Csem(WHILE S DO C)) q = As. Vn. IterWIp n (Ssem 5) (Csem C) q s 

4.3.3 Syntactic preconditions and expressibility 

We now discuss how to define statements wlp(C ,Q) with properties Pi and 
P 2 , namely: 



Note that wlp operates on syntactic things (commands and statements), 
whereas Wlp operates on semantic things (mathematical functions on states 
representing the meaning of commands and statements). 

We will define wlp(C,Q) recursively on C and justify Pi and P 2 by 
structural induction on C. The cases when C is an assignment, sequence or 
conditional are straightforward. 

| wlp((V:=E),Q) =QIE/V] } 

If C is V:=E then Pi is just the assignment axiom and by the equation for 
Wlp (Csem (V :=E)) (Ssem Q) discussed on page 63, P 2 is the equation: 

Ssem (QIE/V1) s = Ssem Q (s[(Esem E s)/V]) 

which was justified in the "Diversion on substitution" on page 55. 

| wlp((Ci;C 2 ),Q) =wlp(Ci,wlp(C 2 ,Q)) 1 

Assume Pi and P 2 hold for C\ and C 2 for arbitrary Q. Then: 

h {wlp(C 2) Q)}C 2 {Q} 

h {wlp(Ci,(wlp(C 2 ,Q)))}Ci {(wlp(C 2 ,g))} 



h {wip(c ) g)}c{g} 

Ssem (wlp(C,Q)) = Wlp (Csem C)(Ssem Q) 



(Pi) 
(P 2 ) 



66 



Chapter 4. Soundness and Completeness 



hence Pi by the sequencing rule. To show P 2 when C is did note that P 2 
in this case is: 

Ssem (wlp(Ci,wlp(C 2 ,Q))) 
= Wlp (Asi s 2 . 3s. Csem d s t s A Csem C 2 s s 2 )(Ssem Q) 
= Asi. Vs 2 . (3s. Csem Ci «i s A Csem C 2 s s 2 ) =>- Ssem Q s 2 
= Asi. Vs s 2 . (Csem C\ s\ s A Csem C 2 s s 2 ) =>- Ssem Q s 2 

Expanding the LHS using induction twice with P 2 instantiated with C as C\ 
and Q as wlp(C 2 ,Q) and also with C as C 2 and Q just as Q gives: 

Wlp (Csem Ci) (Wlp (Csem C 2 ) (Ssem Q)) 
= Asi. Vs s 2 . (Csem Ci si s A Csem C 2 s s 2 ) ^> Ssem Q s 2 

Expanding the LHS using the definition of Wlp then gives: 

Asi. Vs. Csem Ci si s =>• Vs 2 . Csem C 2 s s 2 =>■ Ssem Q s 2 
= Asi. Vs s 2 . (Csem d s 1 s A Csem C 2 s s 2 ) ^> Ssem Q s 2 

which is true. 

| wlp((lFgTHENC 1 ELSEC 2 ),g) = (gAwlp(d ,g))V(^A(wlp(C 2 ,g)) | 

Note that (S A 5i) V (^S A 5 2 ) means i/S" then Si else S 2 . The former is 
used to emphasis that all we are assuming about the specification language 
is the existence of Boolean operators A and V. Note that by Boolean 
algebra and the definition of wlp ((IF S THEN d ELSE C 2 ) , Q) : 

S A wlp((lF S THEN d ELSE C 2 ) , Q) = S A wlp id , Q) 
- 1 SAwlp((lF 1 STHENC 1 ELSEC 2 ),Q) = -*S A wlp(C 2 ,Q) 

By induction, Pi for Ci and C 2 and precondition strengthening: 

{ 1 SAwip(c 1) g)}c 1 {g} 

{^SAwlp(C 2) Q)}C 2 {Q} 
Hence by the conditional rule, substituting with the equations above: 

{wlp((lF S THEN d ELSE C 2 ) ,Q)} IF S THEN Ci ELSE C 2 {Q} 

which is Pi for conditionals. Property P 2 is: 

Ssem ((S A wlpCCi.Q)) V (-.5 A (wlp(C 2 ,Q))) 
= Wlp (Csem (IF S THEN Ci ELSE C 2 ))(Ssem Q) 

Expanding the RHS of this equation: 
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Ssem ((S A wlpCd.Q)) V (-.5 A (wlp(C 2 ,Q))) 
= Wlp 

(Asi s 2 . i/ Ssem 5 si i/ien Csem Ci Si s 2 else Csem C 2 Si s 2 ) 
(Ssem Q) 
= Wlp 

(Asi s 2 . (Ssem S s± A Csem Ci si s 2 ) V (-iSsem S si A Csem C 2 si s 2 )) 
(Ssem Q) 
= Asi. 

Vs 2 . (Ssem S s 1 A Csem Ci Si s 2 ) V (-iSsem S s± A Csem C 2 si s 2 ) 
=>• Ssem Q s 2 

Now we expand the LHS: 

Ssem ((S A wlpCd ,Q)) V (-.5 A (wlp(C 2 ,Q))) 
= Asi. (Ssem 5 si A Ssem (wlp(Ci.Q)) si) 

V 

(^Ssem 5 si A Ssem (wlp(C 2 ,Q)) si) 
= Asi. (Ssem 5 si A Wlp (Csem d) (Ssem Q) Sl ) 

V 

(^Ssem S Si A Wlp (Csem C 2 ) (Ssem Q) si) 
= Asi. (Ssem S s± A (As. Vs'. Csem Ci s s' =>• Ssem Q s') si) 

V 

(-iSsem S si A (As. Vs'. Csem C 2 s s' =>- Ssem Q s') si) 
= Asi. (Ssem S s± A Vs'. Csem C\ s\ s' =>• Ssem Q s') 

V 

(-iSsem S Si A Vs'. Csem C 2 s 1 s' =>- Ssem Q s') 
Combining simplified LHS and RHS equations: 

Asi. (Ssem S si A Vs'. Csem C\ s\ s' =>- Ssem Q s') 

V 

(-■Ssem S si A Vs'. Csem C 2 si s' =>• Ssem Q s') 
= Asi. 

Vs 2 . (Ssem S si A Csem C\ s\ s 2 ) V (-iSsem S s 1 A Csem C 2 si s 2 ) 
=>- Ssem Q s 2 
which is true. Thus P 2 holds for conditionals. 

We are now left with defining wlp ( (WHILE S DO C) ,Q) so that P 1 and 
P 2 hold. This is trickier than the previous cases. Notice that when defin- 
ing wlp(C,<3) for assignments we just needed the specification language 
to allow textual substitution of expressions for variables and for condi- 
tionals we just needed the specification language to allow Boolean com- 
binations of statements. The usual specification language when relative 
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completeness is discussed is first order arithmetic. It is possible to define 
wlp( (WHILE S DO C) ,Q) for this language, but the details are fiddly. An ex- 
cellent account can be found in Glynn Winskel's textbook [24, Chapter 7}. 
We shall instead assume more powerful features than are necessary in order 
to get a straightforward representation of WHILE-loop weakest preconditions. 
Specifically, we assume infinite conjunctions are allowed. What this means 
is that if we have an infinite family of statements, say S n for each natural 
number n, then we allow an 'infinite' formula /\n. S n which means S n is 
true for every n G Num, i.e. So A S 1 A S 2 ■ ■ ■ A S n A • • • . Infinite conjunctions 
enable us to mimic the semantic definition in the specification language. The 
semantics definition is: 

Wlp (Csem(WHILE,SDO C)) q 

= As. Vra. IterWIp n (Ssem S) (Csem C) s 
where IterWIp 0 p c q = As. ->{p s) =>• q s 

IterWIp (n+1) p c q = As. p s =>- Wlp c (IterWIp n p c q) s 
the definition below in the specification language mimics this: 
wlp^WHILESDO C),Q) 

= /\n. iterwlp n S C Q 
where iterwlp 0 S C Q = (->S Q) 

iterwlp (n+1) S C Q = (S => wlp (C, (iterwlp n S C Q))) 
Thus wlp ( (WHILE S DO C) , Q) = iterwlp 0 S C Q A iterwlp 1 S C Q ■ ■ ■ 
so in terms of the discussion of infinite conjunction above, we are taking 
S n to be iterwlp n S C Q. In Winskel's book it is shown how Godel's 
/3-function 1 can be used to build a finite first order formula expressing 
wlp ( (WHILE S DO C) ,Q), so infinite conjunctions are not needed. However, 
we use the infinite formula above since it makes verifying Pi and P2 straight- 
forward. 

To show Pi, i.e. h {wlp((WHILE S DO C) ,Q) } WHILE S DO C {Q}, it is 
sufficient to find an invariant R (perhaps provided by an annotation) such 
that: 

h wlpCWHILESDOCQ) R 

h RA^S^Q 
h {R A S} C {R} 

Pi will then follow by the WHILE-rule and consequence rules. In fact taking 
R to be wlp (WHILE S DO C ,Q) will work! The first of the three conditions 
1 http://planetmath.org/encyclopedia/GodelsBetaFunction.html 
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above is trivial. The second is almost trivial: iterwlp 0 S C Q is -<S =>- Q, 
so h (f\n. iterwlp n S C Q) (-<S Q), hence: 

h (f\n. iterwlp n S C Q) A Q 

i.e.: 

h wlp(WHILESDOC,Q) A^S^Q 
For the third property we have by induction, for arbitrary n: 

h {wlp(C, iterwlp n S C Q)} C {iterwlp n S C Q} 
Hence by the definition of iterwlp and precondition strengthening: 

h {(iterwlp (n+1) S C Q) A S} C {iterwlp n S C Q} 
Applying the rule of specification conjunction infinitely many times: 

h {f\n. (iterwlp (n+1) S C Q) A S} C {/\ n. iterwlp n S C Q} 

In general h (f\n. S n ) ^> (f\n. S n+ i) for any infinite set of statements 
S'o, Si, ... since the set of statements being conjoined in the consequent of 
the implication is a subset of the set being conjoined in the antecedent. Thus 
by precondition strengthening applied to the Hoare triple above: 

h {f\n. (iterwlp n S C Q) A S} C {/\ n. iterwlp n S C Q} 

In general h (f\n. (S n AS)) ((A n - S n )AS), so by precondition strength- 
ening: 

h {(/\n. iterwlp n S C Q) A S} C {/\ n. iterwlp n S C Q} 

which by the definition of wlp (WHILE SWC,Q) is: 

h {wlp(WHILE 5 DO C,Q) A 1 S}C{wlp(WHILE 1 SDOC,g)} 

This is the desired invariance property of R. We have thus proved Pi when 
C is WHILE S DO C. 

To show P 2 , we must show: 

Ssem (wlp (WHILE S DO C ,Q)) = Wlp (Csem (WHILE S DO C)) (Ssem Q) 

i.e.: 

Ssem (f\n. iterwlp n S C Q) 

= Wlp (Xsi s 2 . 3n. Iter n (Ssem S) (Csem C) s x s 2 ) (Ssem Q) 

= As. W. (Xsi s 2 . 3n. Iter n (Ssem S) (Csem C) si s 2 ) n'4 (Ssem Q) s' 

= As. Vs'. (3n. Iter n (Ssem S) (Csem C) s s') =^ Ssem Q s' 

= As. Vs' n. Iter n (Ssem S) (Csem C) s s' Ssem Q s' 
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Now Ssem (/\n. iterwlp n S C Q) s Vn. Ssem (iterwlp n S C Q) s so 
we need to show for arbitrary s that: 

Vn. Ssem (iterwlp n S C Q) s 

= Vs' n. Iter n (Ssem 5) (Csem C) s s' =>- Ssem Q s' 

We will show by induction of n that: 

Ssem (iterwlp n S C Q) s 

= Vs'. Iter n (Ssem S) (Csem C) s s' =>- Ssem Q s' 
This is sufficient as Vn. (Pi n = P 2 n) implies (Vn. Pi n) = (Vn. P 2 n). Recall 
the definitions of Iter and iterwlp: 

Iter 0 p c si s 2 = ~"{p Si) A (s 1 =s 2 ) 

Iter (n+1) p c Si s 2 = P «i A 3s. c si s A Iter n p c s s 2 

iterwlp OSCQ = (-.5 Q) 

iterwlp (n+1) 5 C Q = (S wlp(C, (iterwlp n S C Q))) 
The basis case (n = 0) is: 

Ssem (iterwlp 0 S C Q) s 

= Vs'. Iter 0 (Ssem S) (Csem C) s s' Ssem Q s' 

i.e.: 

(-•(Ssem S s') =^ Ssem Q s') 

= Vs'. HSsem S s) A (s = s')) ^ Ssem Q s' 

This is clearly true. The induction step case is 

Ssem (iterwlp (n+1) S C Q) s 

= Vs'. Iter (n+1) (Ssem S) (Csem C) s s' =>• Ssem Q s' 
Unfolding Iter and iterwlp yields: 

Ssem (S =^wlp(C, (iterwlp n S C Q))) s 

= Vs'. (Ssem S s A 3s". Csem C s s" A Iter n (Ssem 5) (Csem C) s" s') 
=>• Ssem Q s' 

Evaluating the LHS: 

(Ssem S s =>• Ssem (wlp(C, (iterwlp nSC Q))) s) 
= Vs'. (Ssem 5 s A 3s". Csem C s s" A Iter n (Ssem 5) (Csem C) s" s') 
^> Ssem Q s' 

Using P 2 by the structural induction hypothesis (note we are doing a math- 
ematical induction on n inside the structural induction on C to prove P 2 ). 

(Ssem S s Wlp (Csem C) (Ssem (iterwlp n S C Q)) s) 
= Vs'. (Ssem S s A 3s". Csem C s s" A Iter n (Ssem 5) (Csem C) s" s') 
=>• Ssem Q s' 



4.4. Verification conditions via wlp 



71 



Expanding Wlp: 

(Ssem S (As. Vs'. (Csem C) s s' (Ssem (iterwlp n S C Q)) s') s) 
= Vs'. (Ssem 5 s A 3s". Csem C s s" A Iter n (Ssem 5) (Csem C) s" s') 
=>- Ssem Q s' 

Reducing the LHS: 

(Ssem S s =>- Vs'. Csem C s s' =>• Ssem (iterwlp n S C Q) s') 
= Vs'. (Ssem S s A 3s". Csem C s s" A Iter n (Ssem S) (Csem C) s" s') 
=>• Ssem Q s' 

The induction hypothesis for the induction on n we are doing is: 
Ssem (iterwlp n S C Q) s 

= Vs'. Iter n (Ssem S) (Csem C) s s' =>- Ssem Q s' 
From this and the preceding equation: 
(Ssem S s 

Vs'. Csem C s s' (Vs". Iter n (Ssem S) (Csem C) s' s" Ssem Q s 
= Vs'. (Ssem S s A 3s". Csem C s s" A Iter n (Ssem S) (Csem C) s" s') 
=^> Ssem Q s' 

Which simplifies to: 

(Ssem S s 

=^ Vs' s". Csem C s s' => Iter n (Ssem 5) (Csem C) s' s" ^> Ssem Q s") 
= Vs' s". (Ssem S s A Csem C s s" A Iter n (Ssem S 1 ) (Csem C) s" s') 
^> Ssem Q s' 

Switching s' and s" in the RHS and pulling quantifiers to the front: 

(Vs' s". Ssem 5 s 

^> Csem Iter n (Ssem 5 1 ) (Csem C) s' s" ^> Ssem Q s") 

= Vs' s". (Ssem S s A Csem Css'A Iter n (Ssem S') (Csem C) s' s") 
^> Ssem Q s" 

which is true. Thus we have proved P 2 when C is WHILE S DO C. This was 
the last case so we have now proved Pi and P 2 for all commands C. 



4.4 Verification conditions via wlp 

Weakest preconditions provide a way to understand verification conditions 
and to improve them. Recall property Pi: h {wlp {C , Q) } C {Q}- To prove 
{P} C {Q} it is thus sufficient (by precondition strengthening) to prove: 
h P =>- wlp(C,Q) and thus one can view P =^ wlp(C,Q) as a single 'super 
verification condition' for the goal {P} C {Q} which is generated without 
having to annotate C\ This works fine if C is loop-free, i.e. contains no 
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WHILE-commands. If C does contain WHILE-commands then wlp(C,Q) will 
be an infinite statement. 2 Proving such a statement will typically involve 
proving by induction what is essentially the verification condition for an in- 
variant. There is thus no getting away from finding invariants! However, 
it is possible to use the idea of weakest preconditions to both explain and 
improve the verification condition method. To see how it explains verifica- 
tion conditions recall from page 43 that the verification condition generated 
by: {P} d ; . . . ; C n _i ; V : =E {Q} is: {P} d ; . . . ; C n _i {Q IE /VI } which 
is {P} C\ \ . . . ;C n -i {wlp(V :=E ,Q)}. We can generalise this observation 
to reduce the number of annotations needed in sequences by only requir- 
ing annotations before commands that are not loop-free (i.e. contain WHILE- 
commands) and then to modify the verification conditions for sequences: 

Sequences 

1. The verification conditions generated by 

{P} C i; ...;C n _ i; {R}C n {Q} 
(where C n contains a WHILE-command) are: 

(a) the verification conditions generated by 

{P} (^...jCU {R} 

(b) the verification conditions generated by 

{R} C n {Q} 

2. The verification conditions generated by 

{P} C i; ...;C n _ i; C n {Q} 
(where C n is loop-free) are the verification conditions generated by 
{P} d; ... ;C n _! {wlp(C n ,Q)} 



The justification of these improved verification conditions is essentially the 
same as that given for the original ones, but using Pi rather than the as- 

2 It is possible to represent wlp (WHILE S DO C ,Q) by a finite statement in a first order 
theory of arithmetic, but the statement is not suitable for use in actual verifications [24]. 
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signment axiom. However, using wlp ideas we can do even better and reduce 
the requirement for annotations to just invariants of WHILE- commands. The 
outline of the method is as follows: 

• define awp(C,<5) which is similar to wlp(C,<5) except for WHILE- 
commands, which must be annotated; 

• define a set of statements wvc(C ,Q) giving the conditions needed to 
verify that user-annotated invariants of all WHILE-loops in C really are 
invariants. 

It will follow from the definitions of awp and wvc that the conjunction of the 
statements in wvc(C ,Q) entails {awp(C ,Q)} C {Q}. If we define /\<S to be 
the conjunction of all the statements in S, then this can be written as: 

h Awvc(C,Q)^{awp(C,Q)}C{Q}. 

Hence by Modus Ponens and precondition strengthening, to prove 
{P} C {Q} it is sufficient to prove h /\wvc(C, Q) and h P^awp(C,Q). 
If C is loop-free then it turns out that awp(C,Q) = wlp(C,Q) and 
wvc(C,<5) = {}, so this method collapses to just proving h P =^> 
wlp(C ,Q) . The definitions of awp(C,Q) and wvc(C,Q) are recursive on C 
and are given below. It is assumed that all WHILE-commands are annotated: 
WHILE S DO {R} C. 

awp(V :=E,Q) =QIE/V] 

awp(C 1 ; C 2 ,Q) = awp(d, awp(C 2 ,g)) 

awp(lF S THEN C x ELSE C 2 , Q) — (S A awp(Ci, Q)) V (^S A awp(C 2 , Q)) 

awp(WHILE S DO {R} C,Q) = R 



wvc(lF S THEN Ci ELSE C 2 , Q) = wvc(C 1 , Q) U wvc(C 2 , Q) 
wvc(WHILE S DO {R} C,Q) = {R A Q, R A S awp(C, R)} 

U wvc(C, R) 



wvc(\/ := E,Q) 
wvc(C 1 ; C 2 ,Q) 



{} 

wvc(Ci, awp(C 2 , Q)) U wvc(C 2 , Q) 
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Theorem /\wvc(C,Q) {awp(C,Q)} C {Q}. 

Proof outline 

Induction on C. 
C = V:=E. 

Awvc(y :=E,Q) {awp(C,Q)} C {Q} is T {QIE/V]} V : = E {Q} 
C = C 1 ;C 2 . 

Awvc(Ci;C 2 ,g) =s> {awp(Ci ;C 2 ,Q)} C i; C 2 {Q} is 

A(wvc(C 1 ,awp(C , 2 ,g))Uwvc(C 2 ,g)) {awp(d, awp(C 2 ,g))} C i; C 2 {Q}. 
By induction f\wvc{C 2 ,Q) {awp(C 2 ,g)} C 2 {Q} 
and Awvc(Ci, awp(C 2 , Q)) {awp(Ci, awp(C 2 , Q))} Ci {awp(C 2 ,g)}, 
hence result by the Sequencing Rule. 
C = IF S THEN d ELSE C 2 . 
Awvc(lF S THEN Ci ELSE C 2 , Q) 

{awp(lF S THEN C x ELSE C 2 ,g)} IF 5 THEN d ELSE C 2 {g} 
. /\(wvc(C 1 ,Q)Uwvc(C 2 ,Q)) 

18 ^{(SA awp(Ci, gj) V (-5 A awp(C 2 , Q)} IF S THEN d ELSE C 2 {Q} ' 

By induction Awvc(Ci,Q) =>• {awp(Ci,Q)} Ci {g} 

and /\wvc(C 2 ,Q) =>• {awp(C 2 ,g)} C 2 {g}. Strengthening preconditions 

gives Awvc(Ci,Q) {awp(Ci,Q) A 5} Ci {g} 

and f\wvc(C 2 ,Q) {awp(C 2 ,g) A ^5} C 2 {g}, hence 

Awvc(Ci, g) ^{((sa aw P (Ci, g)) v (-.s- a aw P (c 2 , g))) a 5} d {g} 

and Awvc(C 2 ,g) => {((S Aawp(Ci, Q)) V(-SAawp(C 2 , Q))) A-S} C 2 {g}, 
hence result by the Conditional Rule. 
C = WHILE 5 DO C. 

Awvc(WHILE S DO {i?} C, Q) {awp(WHILE S DO {R} C, Q)} WHILE S DO {i?} C {g} 
is A({^ A -iS Q, R A S awp(C,i?)} U wvc(C,R)) 

{R} WHILE 5 DO {i?} C {Q}. 

By induction f\wvc(C,R) {awp(C,i?)} C {R}, hence result by WHILE- 

Rule. 

Q.E.D. 
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Example 

awp(R:=R-Y;Q:=Q+l, X = R + Y x Q) 
= wlp(R:=R-Y;Q:=Q+l, X = R + Y x Q) 
= X = R-Y + Y x Q+l 

awp(WHILE Y < R DO {X = R + Y x Q} R:=R-Y;Q:=Q+1, X = R+YxQ A R<Y) 
= X = R + Y x Q 

awp(Q:=0; WHILE Y < R DO {X = R + Y x Q} R:=R-Y; Q:=Q+1, X = R+YxQ A R<Y) 
= X = R + Y x 0 

awp(R=X;Q:=0; WHILE Y < R DO {X = R + Y x Q} R:=R-Y; Q:=Q+1, X = R+YxQ A R<Y) 
=X=X+YxO 

wvc(R:=R-Y;Q:=Q+l, X) = {} 

wvc(WHILE Y < R DO {X = R + Y x Q} R:=R-Y;Q:=Q+1, X = R+YxQ A R<Y) 
= {X = R + Y x Q A -.(Y < R) =>• X = R+YxQ A R<Y, 
X = R + YxQAY<R^X = R-Y + Yx Q+l} U {} 

wvc(Q:=0; WHILE Y < R DO {X = R + Y x Q} R:=R-Y; Q:=Q+1, X = R+YxQ A R<Y) 
= {} u {X = R + Y x Q A -.(Y < R) =^> X = R+YxQ A R<Y, 
X = R + YxQAY<R^X = R-Y + Yx Q+l} 

wvc(R=X; Q:=0; WHILE Y < R DO {X = R + Y x Q} R:=R-Y; Q:=Q+1, X = R+YxQ A R<Y) 
= {} u {X = R + Y x Q A -.(Y < R) =>■ X = R+Yx Q A R<Y, 
X = R + YxQAY<R^X = R-Y + Yx Q+l} 

X = X + Y x 0 is T so by the theorem proved above: 

h (X = R + YxQA -i(Y < R) =^> X = R+YxQ A R<Y 

A 

X = R + YxQAY<R^X = R-Y + Yx Q+l) 

{T} R=X;Q:=0; WHILE Y < R DO {X = R + Y x Q} {X = R+YxQ A R<Y} 

The calculation of awp(C,Q) and uvc(C ,Q) is not that different from clas- 
sical verification condition generation, but has the advantage of requiring 
fewer annotations. 

4.4.1 Strongest postconditions 

Weakest preconditions are calculated 'backwards' starting from a postcon- 
dition. There is a dual theory of strongest postconditions that are calcu- 
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lated 'forwards' starting from a precondition. The strongest postcondition 
sp (C,P) has the property that h {P} C {sp(C ,P)} and is strongest in 
the sense that for any Q: if h {P} C {Q} then h sp(C,P) =>• Q. Intu- 
itively sp (C,P) is a symbolic representation of the state after executing C 
in an initial state described by P. For assignments: 
sp(V:=E,P) =3v. (V = Elv/V]) A P[v/V]} 

The existentially quantified variable v is the value of V in the state before 
executing the assignment (the initial state). The strongest postcondition 
expresses that after the assignment, the value of V is the value of E evaluated 
in the initial state (hence E[v/V]) and the precondition evaluated in the 
initial state (hence Plv/V"]) continues to hold. Thus if the initial state is 
represented symbolically by the statement (V = v ) A P then the state after 
executing V :=E is represented symbolically by (V = E [v/V~\ ) A P [v/V~\ . 

For loop-free commands C, the calculation of sp(C,P) amounts to the 
'symbolic execution' of C starting from a symbolic state P. An advantages 
of symbolic execution is that it can allow the representation of the symbolic- 
state-so-far to be simplified 'on-the-fly', which may prune the statements 
generated (e.g. if the truthvalue of a conditional test can be determined then 
only one branch of the conditional need be symbolically executed). In the 
extreme case when P is so constraining that it is only satisfied by a single 
state, s say, then calculating sp(C,P) collapses to just running Cms- the 
truthvalue of each test is determined so there is no need to consider both 
branches of conditionals [12]. Backwards pruning, though possible, is less 
natural when calculating weakest preconditions. 

Several modern automatic verification methods are based on computing 
strongest postconditions for loop free code by symbolic execution. It is also 
possible to generate strongest postcondition verification conditions for WHILE- 
commands in a manner similar, but dual, to that described above using 
weakest preconditions. However, this is not the standard approach, though 
it may have future potential, especially if combined with backward methods. 

4.4.2 Syntactic versus semantic proof methods 

Originally Hoare logic was a proof theory for program verification that pro- 
vided a method to prove programs correct by formal deduction. In practice, 
only simple programs could be proved by hand, and soon automated methods 
based on verification conditions emerged. The first idea was to convert the 



4.4. Verification conditions via wlp 



77 



problem of proving {P} C {Q} into a purely mathematical/logical problem 
of proving statements in first order logic (i.e. verification conditions) as in the 
early days theorem provers mainly supported first order logic. However, now 
we have theorem proving technology for more expressive logics (e.g. higher 
order logic) that are powerful enough to represent directly the semantics of 
Hoare triples. Thus we now have two approaches to proving {P} C {Q}: 

(i) Syntactic: first generate VCs and then prove them; 

(ii) Semantic: directly prove Hsem (Ssem P) (Csem C) (Ssem Q). 

Both of these approaches are used. The VC method is perhaps more common 
for shallow analysis of large code bases and the semantic method for full proof 
of correctness, though this is an oversimplification. 
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Total Correctness 



The axioms and rules of Hoare logic are extended to total correct- 
ness. Verification conditions for total correctness specifications 
are given. 



In Section 1.3 the notation [P] C [Q] was introduced for the total correct- 
ness specification that C halts in a state satisfying Q whenever it is executed 
in a state satisfying P. At the end of the section describing the WHILE-rule 
(Section 2.1.8), it is shown that the rule is not valid for total correctness spec- 
ifications. This is because WHILE-commands may introduce non-termination. 
None of the other commands can introduce non-termination, and thus the 
rules of Hoare logic can be used. 

5.1 Non- looping commands 

Replacing curly brackets by square ones results in the following axioms and 
rules. 

Assignment axiom for total correctness 

h [PIE /VI] V:=E [P] 

Precondition strengthening for total correctness 

h P =» P', h [P'} C [Q] 
l- [P] C [Q] 

Postcondition weakening for total correctness 

h [P]C[Q>], h Q'^Q 
I- [P] C [Q] 
79 
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Specification conjunction for total correctness 

h [Pi] C [Qx], h [P 2 ] C [Q 2 ] 
h [Pi A P 2 ] C [Qi A Q 2 ] 



Specification disjunction for total correctness 

h [Px] C [Qx], h [P 2 ] g [Q 2 ] 
h [Pi V P 2 ] C [Qx V Q 2 \ 

Sequencing rule for total correctness 

h [P] d [Q], h [Q] C 2 [P] 
h [P] Ci;C 2 [P] 

Derived sequencing rule for total correctness 

h P^P X 
^ [Pi] Ci [Qx] h Qx P 2 
I- [P 2 ] C 2 [Q 2 ] h Q 2 P 3 

H [P„] C n [Q n ] h Q n ^Q 



h [P] Ci; . . . ; C n [Q] 

Conditional rule for total correctness 

h [PAS] gx [Q], h [PAng] C 2 [Q] 
h [P] IF 5 THEN Ci ELSE C 2 [Q] 

The rules just given are formally identical to the corresponding rules of 
Hoare logic, except that they have [ and ] instead of { and }. It is thus clear 
that the following is a valid derived rule. 

— ^ J. ^ C contains no WHILE-commands 
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5.2 The termination of assignments 

Note that the assignment axiom for total correctness states that assignment 
commands always terminate, which implicitly assumes that all function ap- 
plications in expressions terminate. This might not be the case if func- 
tions could be defined recursively. For example, consider the assignment: 
X := fact(-l), where fact(n) is defined recursively by: 

fact(n) = if n = 0 then 1 else n x fact(n — 1) 

It is also assumed that erroneous expressions like 1/0 do not cause problems. 
Most programming languages will cause an error stop when division by zero 
is encountered. However, in our logic it follows that: 

h [T] X : = 1/0 [X = 1/0] 

i.e. the assignment X := 1/0 always halts in a state in which the condition 
X = 1/0 holds. This assumes that 1/0 denotes some value that X can have. 
There are two possibilities: 

(i) 1/0 denotes some number; 

(ii) 1/0 denotes some kind of 'error value'. 

It seems at first sight that adopting (ii) is the most natural choice. However, 
this makes it tricky to see what arithmetical laws should hold. For example, is 
(1/0) x 0 equal to 0 or to some 'error value' ? If the latter, then it is no longer 
the case that n x 0 = 0 is a valid general law of arithmetic? It is possible to 
make everything work with undefined and/or error values, but the resultant 
theory is a bit messy. We shall assume here that arithmetic expressions 
always denote numbers, but in some cases exactly what the number is will 
1)0 not fully specified. For example, we will assume that m/n denotes a 
number for any m and n, but the only property of "/" that is assumed is: 

->(n = 0) =>- (m/n) x n = m 

It is not possible to deduce anything about m/0 from this. 

Another approach to errors is to extend the semantics of commands to 
allow 'faults' to be results as well as states. This approach is used in Chap- 
ter 7 to handle memory errors, but a similar idea could also handle other 
expression evaluation errors (though at the expense of a more complex se- 
mantics) . 
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5.3 WHILE-rule for total correctness 

WHILE-commands are the only commands in our little language that can 
cause non-termination, they are thus the only kind of command with a non- 
trivial termination rule. The idea behind the WHILE-rule for total correctness 
is that to prove WHILE S DO C terminates one must show that some non- 
negative quantity decreases on each iteration of C. This decreasing quantity 
is called a variant. In the rule below, the variant is E, and the fact that 
it decreases is specified with an auxiliary variable n. An extra hypothesis, 
h P A S ^> E > 0, ensures the variant is non-negative. 
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h [P A S A (E = n)} C [P A (E < n)}, h P A S =» E > 0 
h [P] WHILE S DO C [P A ~^S] 

where E is an integer- valued expression and n is an auxiliary variable not 
occurring in P, C, S or E. 

Example: We show: 

h [Y>0] WHILE Y<R DO (R:=R-Y; Q:=Q+1) [T] 

Take 

P = Y > 0 
S = Y < R 
E = R 

C = (R:=R-Y Q:=Q+1) 
We want to show h [P] WHILE S DO C [T]. By the WHILE-rule for total 
correctness it is sufficient to show: 

(i) h [P A S A (E = n)] C [P A (E < n)] 

(ii) h PAS^E>0 

and then use postcondition weakening to weaken the postcondition in the 
conclusion of the WHILE-rule to T. Statement (i) above is proved by showing: 

h {P A S A (E = n)} C {P A (E < n)} 
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and then using the total correctness rule for non-looping commands. The 
verification condition for this partial correctness specification is: 

Y>0 A Y < R A R = n =>• (Y>0A R < n) [Q+l/Q] [R-Y/R] 

i.e. 

Y>0 A Y < R A R = n Y>0A R-Y < n 

which follows from the laws of arithmetic. 

Statement (ii) above is just h Y>0 A Y < R ^ R > 0, which follows 
from the laws of arithmetic. 

5.4 Termination specifications 

As already discussed in Section 1.3, the relation between partial and total 
correctness is informally given by the equation: 

Total correctness = Termination + Partial correctness. 

This informal equation above can now be represented by the following 
two formal rule of inferences. 

h {P} C {Q}, h [P] C [T] 
h [P] C [Q] 

H [P] C [Q] 

h {P} C {Q}, h [P] C [T] 

5.5 Verification conditions for termination 

The idea of verification conditions is easily extended to deal with total cor- 
rectness. We just consider the simple approach of Chapter 3 here, but the 
improved method based on weakest preconditions described in Section 4.4 is 
easily adapted to deal with termination. 

To generate verification conditions for WHILE-commands, it is necessary 
to add a variant as an annotation in addition to an invariant. No other extra 
annotations are needed for total correctness. We assume this is added directly 
after the invariant, surrounded by square brackets. A correctly annotated 
total correctness specification of a WHILE-command thus has the form 

[P] WHILE S DO {R}[E\ C [Q] 
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where R is the invariant and E the variant. Note that the variant is intended 
to be a non-negative expression that decreases each time around the WHILE 
loop. The other annotations, which are enclosed in curly brackets, are meant 
to be conditions that are true whenever control reaches them. The use of 
square brackets around variant annotations is meant to be suggestive of this 
difference. 

The rules for generating verification conditions from total correctness 
specifications are now given in the same format as the rules for generating 
partial correctness verification conditions given in Section 3.4. 

5.6 Verification condition generation 

Assignment commands 

The single verification condition generated by 

[P]V:=E [Q] 

is 

P ± QIE/V] 

Example: The single verification condition for: [X=0] X:=X+1 [X=l] is: 
X=0 =>- (X+l)=l. This is the same as for partial correctness. 

Conditionals 

The verification conditions generated from 

[P] IF S THEN d ELSE C 2 [Q] 

are 

(i) the verification conditions generated by [P A S] C\ [Q] 

(ii) the verifications generated by [P A ->S] C 2 [Q] 

If Ci ; . . . ; C n is properly annotated, then (see page 41) it must be of one 
of the two forms: 

1. Ci; ... ;C n _! or 

2. Ci; ... ;C n _i;V := E. 
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So 



where, in both cases, C\\ ... ; C ra _i is a properly annotated command. 
Sequences 

1. The verification conditions generated by: 

[P] Cr,. ..;C„ ,; {R} C n [Q] 
(where C n is not an assignment) are: 

(a) the verification conditions generated by 

[P] C 1 ;...;C n . 1 [R] 

(b) the verification conditions generated by 

[R] C n [Q] 

2. The verification conditions generated by 

[P] C 1 ;...;C n _ 1 ;V:=E [Q] 
are the verification conditions generated by 

[P] Ci; ... ;C n _i [QIE/Vl] 

Example: The verification conditions generated from 

[X=x A Y=y] R:=X; X:=Y; Y:=R [X=y A Y=x] 
are those generated by 

[X=x A Y=y] R:=X; X:=Y [(X=y A Y=x)[R/Y]] 
which, after doing the substitution, simplifies to 

[X=x A Y=y] R:=X; X:=Y [X=y A R=x] 
The verification conditions generated by this are those generated by 

[X=x A Y=y] R:=X [(X=y A R=x)[Y/X]] 
which, after doing the substitution, simplifies to 
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[X=x A Y=y] R:=X [Y=y A R=x] . 
The only verification condition generated by this is 

X=x A Y=y (Y=y A R=x) [X/R] 
which, after doing the substitution, simplifies to 

X=x A Y=y Y=y A X=x 

which is obviously true. 

A correctly annotated specification of a WHILE-command has the form 
[P] WHILE S DO {R}[E} C [Q\ 
The verification conditions are: 

WHILE-commands 

The verification conditions generated from 

[P] WHILE S DO {R}[E\ C [Q] 

are 

(i) P R 

(ii) R A -^S Q 

(iii) R A S E > 0 

(iv) the verification conditions generated by 

[R A S A (E = n)\ C[R A (E < n)\ 
where n is an auxiliary variable not occurring in P, C, S R, E, Q. 



Example: The verification conditions for 
[R=X A Q=0] 

WHILE Y<R DO {X=R+YxQ}[R] 

(R:=R-Y; Q=Q+1) 
[X = R+(YxQ) A R<Y] 

are: 
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(i) R=X A Q=0 =>• (X = R+(YxQ)) 

(ii) X = R+YxQ A -i(Y<R) (X = R+(YxQ) A R<Y) 

(iii) X = R+YxQ A Y<R =>■ R>0 

together with the verification condition for 

[X = R+(YxQ) A (Y<R) A (R=n)] 

(R:=R-Y; Q:=Q+1) 
[X=R+(YxQ) A (R<n)] 

which (exercise for the reader) consists of the single condition 

(iv) X = R+(YxQ) A (Y<R) A (R=n) X = (R-Y) + (Yx (Q+l) ) A ((R-Y)<n) 
But this isn't true (take Y=0)! 

We leave it as an exercise for the reader to extend the argument given in 
Section 3.5 to a justification of the total correctness verification conditions. 
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Program Refinement 



Floyd-Hoare Logic is a method of proving that existing programs 
meet their specifications. It can also be used as a basis for 'refin- 
ing' specifications to programs - i.e. as the basis for a program- 
ming methodology. 



6.1 Introduction 

The task of a programmer can be viewed as taking a specification consisting of 
a precondition P and postcondition Q and then coming up with a command 
C such that h [P] C [Q]. 

Theories of refinement present rules for 'calculating' programs C from 
specification P and Q. A key idea, due to Ralph Back [3] of Finland (and 
subsequently rediscovered by both Joseph Morris [21] and Carroll Morgan 
[20]), is to introduce a new class of programming constructs, called specifica- 
tions. These play the same syntactic role as commands, but are not directly 
executable though they are guaranteed to achieve a given postcondition from 
a given precondition. The resulting generalized programming language con- 
tains pure specifications, pure code and mixtures of the two. Such languages 
are called wide spectrum languages. 

The approach taken here 1 follows the style of refinement developed by 
Morgan, but is founded on Floyd-Hoare logic, rather than on Dijkstra's the- 
ory of weakest preconditions (see Section 4.3.3). This foundation is a bit more 
concrete and syntactical than the traditional one: a specification is identi- 
fied with its set of possible implementations and refinement is represented as 
manipulations on sets of ordinary commands. This approach aims to con- 

1 The approach to refinement described here is due to Paul Curzon. Mark Staples and 
Joakim Von Wright provided some feedback on an early draft, which I have incorporated 
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vey the 'look and feel' of (Morgan style) refinement using the notational and 
conceptual ingredients introduced in the preceding chapters. 
The notation [P, Q] will be used for specifications, and thus: 

[P, Q] = { C | h [P] C [Q] } 

The process of refinement will then consist of a sequence of steps that make 
systematic design decisions to narrow down the sets of possible implemen- 
tations until a unique implementation is reached. Thus a refinement of a 
specification S to an implementation C has the form: 

S D Si D S 2 ■ ■ ■ 2 S n D {C} 
The initial specification S has the form [P, Q] and each intermediate 
specification Si is obtained from its predecessor <Sj_i by the application of a 
refinement law. 

In the literature S D S' is normally written S □ S'. The use of "D" 
here, instead of the more abstract "C", reflects the concrete interpretation 
of refinement as the narrowing down of sets of implementations. 

6.2 Refinement laws 

The refinement laws are derived from the axioms and rules of Floyd-Hoare 
Logic. In order to state these laws, the usual notation for commands is 
extended to sets of commands as follows (C, C±, C 2 etc. range over sets of 
commands) : 

Ci ; • ■ ■ ;C n = { Ci ; • • • ;C n \ & G & A • • • A C n e C n } 

BEGIN VAR Vi ; • • • VAR V n ; C END = { BEGIN VAR V\ ; ■ ■ ■ VAR V n ; C END | C E C } 
IF S THEN C = { IF S THEN C | C G C } 

IF S 1 THEN Ci ELSE C 2 = { IF S THEN Ci ELSE C 2 \ Ci G Ci A C 2 G C 2 } 

WHILE # DO C = { WHILE S 1 DO C | C G C } 

This notation for sets of commands can be viewed as constituting a wide 
spectrum language. 

Note that such sets of commands are monotonic with respect to refine- 
ment (i.e. inclusion). If C D C, C x 2 C[, . . . , C n D C' n then: 
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Cn ■■■ ;C n DC[; ••• ;C' n 

BEGIN VAR V\ ; ■■■ VAR V n ; C END D BEGIN VAR Vi ; • • • VAR V„ ; C END 

IF 5" THEN C 2 IF 5 THEN C 

IF S THEN Ci ELSE C 2 D IF 5 THEN C'j ELSE C' 2 

WHILE 5 DO C D WHILE S 1 DO C 

This monotonicity shows that a command can be refined by separately re- 
fining its constituents. 

The following 'laws' follow directly from the definitions above and the 
axioms and rules of Floyd-Hoare logic. 



The Skip Law 

[P, P] D {SKIP} 



Derivation 

C e {skip} 

<=> C = SKIP 

=> V- [P]C [P] (Skip Axiom) 

& C e[P, P] (Definition of [P, P]) 



The Assignment Law 



[P[E /VI, P] D {V := E} 



Derivation 

Ce {V := E} 

C = V := E 

h [PLE/V1] C [P] (Assignment Axiom) 

& C e [PLE/V1 , P] (Definition of [PIE /VI , P}) 
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Derived Assignment Law 

[P, Q] D {V:=E} 
provided h P => QIE/V1 



Derivation 

Ce{V :=E} 

& C = V := E 

=> h [QLE/V1] C [Q] (Assignment Axiom) 

=> h [P]C[Q] (Precondition Strengthening & h P^Q[E/V~\) 

Ce[P, Q] (Definition of [P, Q}) 



Precondition Weakening 

[P, Q] D [R, Q] 
provided h P =>- R 



Derivation 

C g [R, Q] 

h [R]C [Q] (Definition of [R, Q}) 

=> h [P] C [Q] (Precondition Strengthening & h P => R) 

<S> C G [P, Q] (Definition of [P, Q]) 



Postcondition Strengthening 

[P, Q] D [P, R] 
provided h R =>- Q 



Derivation 

C G [P, R] 

<S> h [P] C [P] (Definition of [P, Q]) 

h [P] C [Q] (Postcondition Weakening & h R^>Q) 

«• C G [P, Q] (Definition of [P, Q]) 
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The Sequencing Law 



[P, Q] D [P, R] ; [R, Q] 



Derivation 

C G [P, R] ; [R, Q] 

C G { d ; C 2 | d e [P P] & C 2 e [P, Q]} (Definition of Ci ; C 2 ) 

C G { d ; C 2 | h [P] Ci [R] & h [P] C 2 [Q]} (Definition of [P, P] and [P, Q]) 

=► C G { d ; C 2 | h [P] Ci ; C 2 [Q]} (Sequencing Rule) 

=* I- [P] C [Q] 

<S> C G [P, Q] (Definition of [P, Q]) 



The Block Law 



[P, Q] D BEGIN VAR V ; [P, Q\ END 

where V does not occur in P or Q 



Derivation 

C G BEGIN VAR V ; [P, Q] END 

^> Ce {BEGIN VAR V ; C" END | 

C" G [P, Q]} (Definition of BEGIN VAR V ; C END) 

<^ Ce {BEGIN VAR V ; C" END | 

h [P] C" [Q]} (Definition of [P, Q]) 

=> Ce {BEGIN VAR V ; C" END | 

h [P] BEGIN VAR V ; C" END [Q]} (Block Rule & V not in P or Q) 
=> I" [P] C [Q] 

^ C7 G [P, Q] (Definition of [P, Q]) 



The One-armed Conditional Law 

[P, Q] D IF 5 THEN [P A 5, Q] 
provided h P A^S =>• Q 
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Derivation 

C G IF S THEN [P A S, Q] 
^ C G {IF 5 THEN C | 

C" G [P A S, Q]} (Definition of IF S THEN C) 

& C G {IF 5 THEN C" | 

h [P A S] C [Q]} (Definition of [P AS, Q\) 

=> C G {IF S THEN C I 

h [P] IF S THEN C" [Q]} (One-armed Conditional Rule & h FA^^-Q) 
=> ^ [P}C [Q] 

«• Ce[P, Q] (Definition of [P, Q\) 



The Two-armed Conditional Law 

[P, Q] D IF S THEN [P A S, Q] ELSE [P A ->S, 



Derivation 

C G IF 5 THEN [PAS', Q] ELSE [PA^S, Q] 
C G {IF S THEN Ci ELSE C 2 | 

Ci G [PAS, Q] & C 2 G [PA^S, Q]} (Definition of IF S THEN Ci ELSE C 2 ) 

C G {IF 5 THEN Ci THEN C 2 | 

h [PAS'] Ci [Q] & h [PA-.5] C 2 [Q]} (Definition of [PAS', Q] k [PA^S, Q}) 
=> C G {IF S THEN Ci ELSE C 2 | 

h [P] IF S THEN Ci ELSE C 2 [Q]} (Two-armed Conditional Rule) 

=> \~[P]C [Q] 

C G [P, Q] (Definition of [P, Q]) 





The While Law 


[P, PA -.S] 


D WHILE S DO [P AS A (E=n), P A {E<n)\ 




provided h P A S ^ P > 0 


where P is an 


integer- valued expression and n is an identifier 


not occurring 


m P, S or E. 
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Derivation 



C e WHILE S DO [P A S A (E = n), P A (E < n)] 
^ C £ {WHILE S DO C | 

C G [P A 5 A (E = n), PA(E< n)]} 
« Ce {WHILE 5 DO C" I 

h [P A 5 A (£ = n)] C [P A (E < n)]} 
C G {WHILE S DOC' | 

h [P] WHILE S DO C" [PAnS]} 
h [P] C [P A -.5] 
^ C G [P, P A 



(Definition of WHILE 5* DO C) 
(Definition of 

[PA5A(£ = n), PA(B<n)]) 

(While Rule & h PAS^ P > 0) 
(Definition of [P, PA-S]) 



6.3 An example 



The notation [Pi, P 2 , P3, • • • , P n -i, P n \ will be used to abbreviate: 



[Pi, P2] ; [P2, Ps}; ■■■ ; [Pn-l, Pn] 



The brackets around fully refined specifications of the form {C} will be 
omitted - e.g. if C is a set of commands, then R := X ; C abbreviates 
{R :=X} ; C. 

The familiar division program can be 'calculated' by the following refine- 
ment of the specification: [Y > 0, X = R + (Y x Q) A R<Y] 

Let X stand for the invariant X = R + (Y x Q). In the refinement that 
follows, the comments in curley brackets after the symbol "3" indicate the 
refinement law used for the step. 
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[Y > 0, X A R < Y] 
3 (Sequencing) 

[Y > 0, R = X A r > 0, X A i?<F] 
3 (Assignment) 

R := X ; [R = X A F > 0, X A i?<F] 
3 (Sequencing) 

R := X ; [R = X A F>0, i? = X A F>0 A Q = 0, X A i?<F] 
3 (Assignment) 

i?:=X;g :=0 ; [i2 = X A F>0 A Q = 0,lA R < Y] 

D (Precondition Weakening) 

R : = X ; Q := 0 ; [Xa Y > 0, X A i? < F] 

D (Postcondition Strengthening) 

i? := X ; Q := 0 ; [X A Y > 0, X A K > 0 A -.(y < R)] 

D (While) 

i? := X ; Q := 0 ; 

WHILE y<i?D0[XA r>0 A Y <R A R = n, 
lAY>0AR<n] 

3 (Sequencing) 
R := X ; Q := 0 ; 

while f<.rdo[Xa r>o a r<i? a r = n, 

X = {R-Y) + {Y xQ) A Y > 0 A (i2 - y) < n, 

XAF>0Ai?<n] 
D (Derived Assignment) 
R := X ; Q := 0 ; 

WHILE y < i? DO [X A Y > 0 A y<i? A = n, 

X = (R - Y) + (Y x Q) A y > 0 A (R-Y) <n] 
R := R-Y 
D (Derived Assignment) 
R := X ; Q := 0 ; 

WHILE Y <R DO Q : = Q + 1 ; i? : = R - Y 



6.4 General remarks 



The 'Morgan style of refinement' illustrated here provides laws for system- 
atically introducing structure with the aim of eventually getting rid of spec- 
ification statements. This style has been accused of being "programming in 
the microscopic" . 

The 'Back style' is less rigidly top-down and provides a more flexible 
(but maybe also more chaotic) program development framework. It also 
emphasises and supports transformations that distribute control (e.g. going 
from sequential to parallel programs). General algebraic laws not specifically 
involving specification statements are used, for example: 

C — IF S THEN C ELSE C 



which can be used both to introduce and eliminate conditionals. 



6.4. General remarks 
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Both styles of refinement include large-scale transformations (data refine- 
ment and superposition) where a refinement step actually is a much larger 
change than a simple IF or WHILE introduction. However, this will not be 
covered here. 
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Chapter 7 



Pointers and Local Reasoning 



Reasoning about programs that manipulate pointers (e.g. in-place 
list reversal) can be done using Hoare logic, but with traditional 
methods it is cumbersome. In the last 10 years a new elegant 
approach based on 'local reasoning' has emerged and given rise to 
a version of Hoare logic called separation logic. 

Programs are represented semantically as relations between initial and 
final states. Up to now states have been represented by functions from vari- 
ables to values. To represent the pointer structures used to represent lists, 
trees etc. we need to add another component to states called the heap. 

7.1 Pointer manipulation constructs 

For the simple (non pointer manipulating) language in previous chapters the 
state was a function mapping variables to values. We now need to add a 
representation of the heap. Following Yang and O'Hearn [25], a store is 
defined to be what previously we called the state. 1 The set Store of stores is 
thus defined by: 

Store = Var — > Val 
Pointers will be represented by locations, which are mathematical abstrac- 
tions of computer memory address and will be modelled by natural numbers. 
The contents of locations will be values, which are assumed to include both 
locations and data values, e.g. integers and nil (see later). The contents of 
pointers are stored in the heap, which is a finite function - i.e. a function with 
a finite domain - from natural numbers (representing pointers) to values. 

Heap = Num — ^f in Val 
where we use the notation A -^/m B to denote the set of finite functions 
from A to B. If / : A B then the domain of / is a finite subset of A 

1 ln early work the store was called the environment [29] and it is now sometimes also 
called the stack. 
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denoted by dom(/) (or dom /) and is the subset of A on which / is defined. 
The notation / lb/a] denotes the function that is the same as / except that 
it maps a to b. If a £ dom(/), then a is added to the domain of fib/ a], 
thus: dom(/[6/a]) = dom(/) U {a}. The notation f-a denotes the function 
obtained from / by deleting a from its domain, thus dom (f-a) = dom(/)\{a} 
(where A\B denotes the set of elements of A that are not in B). The notation 
{I i i-> v i, . . . , l n t-> v n } denotes the finite function with domain {Zi, ...,/„} 
which maps k to Vi (for 1 < i < n). A location, or pointer, is said to be in 
the heap h if it is a member of dom(Zi). 

The new kind of state will be a pair (s, h) where s G Store and h G Heap. 
To extend states to include heaps we redefine the set State of states to be: 

State = Store x Heap 

We add to our language four new kinds of atomic commands that read 
from, write to, extend or shrink the heap. An important feature is that some 
of them can fault. For example, an attempt to read from a pointer that is 
not in the heap faults. The executions of these constructs takes place with 
respect to a given heap. The new commands are described below. 

1. Fetch assignments: V : = IE~\ 

Evaluate E to get a location and then assign its contents to the variable 
V . Faults if the value of E is not in the heap. 

2. Heap assignments: IE{\ :=E 2 

Evaluate E 1 to get a location and then store the value resulting from 
evaluating E 2 as its contents. Faults if the value of E x is not in the 
heap. 

3. Allocation assignments: V : =cons(E 1 , . . . , E n ) 

Choose n consecutive locations that are not in the heap, say /, Z+l, . . ., 
extend the heap by adding these to its domain, assign / to the variable 
V and store the values of expressions E 1 ,E 2 ,... as the contents of 
/, .... This is non-deterministic because any suitable I, Z+l, . . . 
not in the heap can be chosen. Such numbers exist because the heap 
is finite. This never faults. 

4. Pointer disposal: dispose (E) 

Evaluate E to get a pointer Z (a number) and then remove this from the 
heap (i.e. remove it from the domain of the finite function representing 
the heap). Faults if Z is not in the heap. 



7.1. Pointer manipulation constructs 
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Example 

Here is a nonsense sequence of assignments as a concrete illustration: 

X:=cons(0,l,2) ; [X]:=Y+1; [X+l] :=Z; [X+2] : =Y+Z ; Y : = [Y+Z] 

The first assignment allocates three new pointers - say /, Z+l, 1+2 - at 
consecutive locations; the first is initialised with contents 0, the second with 
1 and the third with 2 and the variable X is assigned to point to /. The 
second command changes the contents of I to be the value of Y+l. The 
third command changes the contents of /+1 to be the value of Z. The last 
command changes the value of Y in the store to the contents in the heap of 
the value of the expression Y+Z, considered as a location; this might fault if 
the expression Y+Z evaluates to a number not in the heap. 

For simplicity, expressions only depend on the state not the heap. Thus 
expressions like [Ei] + \_E 2 ] are not allowed. In our language, which is 
adapted from the standard reference [25], only commands depend on the 
heap. Expressions denote functions from stores to values. 

Pointers are used to represent data-structures such as linked lists and 
trees. We need to introduce some specification mechanisms to deal with 
these, which we will do in Section 7.3.5. First, as preparation, we consider 
some simple examples that illustrate subtleties that we have to face. Consider 
the following sequence of assignments: 

X:=cons(0) ; Y:=X; [Y] : =Z ; W : = [X] 

This assigns X and Y to a new pointer, then makes the contents of this 
pointer be the value of Z and then assigns W to the value of the pointer. Thus 
intuitively we would expect that the following Hoare triple holds: 

{T} X:=cons(0) ; Y:=X; [Y] :=Z; W:=[X] {W = Z} 

How can we prove this? We need additional assignment axioms to handle 
fetch, store and allocation assignments. But this is not all ... how can we 
specify that the contents of the pointer values of X and Y are equal to the 
value of the expression Y? This is a property of the heap, so we need to be 
able to specify postconditions whose truth depends on the heap as well as on 
the state. We would also like to be able to specify preconditions on the heap 
so as to be able to prove things like: 

{contents of pointers X and Y are equal} X: = [X] ; Y: = [Y] {X = Y} 
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For example, if X is 1 and Y is 2 in the state, and if both locations 1 and 2 
have contents v in the heap, then the two fetch assignments will assign v to 
both X and Y. 

Separation logic is one of several competing methods for reasoning about 
pointer manipulating programs. It is a development from Hoare logic and 
smoothly extends the earlier material in this course. Separation logic pro- 
vides various constructs for making assertions about the heap and Hoare-like 
axioms and rules for proving Hoare triples that use these assertions. The 
details are quite delicate and have taken many years to evolve, starting from 
work by Rod Burstall in the 1970s [27] then evolving via several only par- 
tially successful attempts until finally, reaching the current form in the work 
of O'Hearn, Reynolds and Yang [26] (this paper contains a short history and 
further references). A good introduction is John Reynolds' course notes [23], 
from which I have taken many ideas including the linked list reversal example 
in the following section. 

7.2 Example: reversing a linked list 

Linked lists are a simple example of a data-structure. We need to distinguish 
the elements of a list - the data - from the pointer structure that represents 
it. Each element of the list is held as the contents of a location and then 
the contents of the successor location is the address of the next element in 
the list. The end of the list is indicated by nil. The diagram below shows 
the list [a, b, c] stored in a linked list data-structure where a is the contents 
of location /, b is the contents of location m and c then contents of n. The 
contents of n+1 is nil, indicating the end of the list. 

| a | m -j > | b j n"^ » | c j nilj 

1 1+1 m m+1 n n+1 

If X has value / in the store, then X points to a linked list holding [a, b, c] . 

The following program reverses a linked list pointed to by X with the 
resulting reversed list being pointed to by Y after the loop halts. 
Y:=nil; 

WHILE -.(X = nil) DO (Z: = [X+1]; [X+l] :=Y; Y:=X; X:=Z) 

Below is a trace of the execution when X points to a linked list holding 
the data list [a, b, c] . A blank line precedes each loop iteration. 
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Store 


Heap 


X = Z, Y =?, Z =? 


Z I—?- a, Z+l i— > m, m^b, m+1 i— >• n, m->c, n+1 s- nil 


X = Z, Y = nil, Z =? 


Z I— > a, Z+l i— > m, m i— y b, m+1 i— > n, n4 c, n+1 i— > nil 






X = Z, Y = nil, Z = m 


Z I—)- a, Z+l i— )■ m, mi-? b, m+1 i— >• n, n i— > c, n+1 i— > nil 


X = Z, Y = nil, Z = m 


I I— > a, Z+l i— > nil, m i— >■ b, m+1 i— > n, n^c, n+1 i— > nil 


X = Z, Y = Z, Z = m 


Z i— > a, Z+l i— > nil, m i— >■ b, m+1 i— y n, n i— >■ c, n+1 i— y nil 


X = m, Y = Z, Z = m 


Z I—?- a, Z+l I—)- nil, m t— > b, m+1 i— >■ n, n \— > c, n+1 i— >■ nil 






X = m, Y = Z, Z = n 


Z i->- a, Z+l i->- nil, m4b, m+1 >->■ n, n^c, n+1 >->■ nil 


X = m, Y = Z, Z = n 


Z ' y a, Z+l ' ^ nil, mnb, m+1 >->■ Z, n4c, n+1 1-> nil 


X = m, Y = m, Z = n 


Z ' ^ a, Z+l ' ^ nil, mnb, m+1 >->■ Z, n^c, n+1 >->■ nil 


X = n, Y = m, Z = n 


Z ' ^ a, Z+l ' nil, mnb, m+1 >-?-/, m->c, n+1 i->- nil 






X = n, Y = m, Z = nil 


Z i — a, Z+l i — y nil, mnb, m+1 >-> I, n i-> c, n+1 >->■ nil 


X = n , Y = m, Z = nil 


Z i — a, Z+l i — nil, mnb, m+1 >->■ Z, n^c, n+1 ^ m 


X = n, Y = n, Z = nil 


I ^ a, Z+l ^ nil, m ^ b, m+1 i-> Z, n ^ c, n+1 ^ m 


X = nil, Y = n, Z = nil 


Z ^ a, Z+l ^ nil, m ^ b, m+1 ^ Z, n ^ c, n+1 ^ m 



Below is a pointer diagram that shows the states at the start of each of 
the three iterations and the final state. The bindings of X, Y and Z in the 
store are shown to the left. The heap is to the right; addresses (locations) of 
the 'cons cell' boxes are shown below them. 



X=l Y=nil Z=? 



X=m Y=l Z=n 



Y=m Z=nil 



X=nil Y=n Z=nil 



a nil |-». b 
1 1+1 [ m 
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To specify that the reversing program works we will formulate a Hoare triple 
that, intuitively, says: 

{X points to a linked list holding x} 
Y:=nil; 

WHILE -.(X = nil) DO (Z: = [X+1]; [X+l] :=Y; Y:=X; X:=Z) 

{Y points to a linked list holding rev(x)} 

where x is an auxiliary variable representing a list (e.g. [a, b, c] ) and rev(x) 
is the reversed list (e.g. [c, b, a]). This is formalised using separation logic 
assertions, which are described in the next section. 

7.3 Separation logic assertions 

In Section 4.2, the semantics of a statement was represented by a predicate on 
states, where what we called states in that section are called stores here. We 
will call such statements classical statements. They correspond to functions 
of type Store — >• Bool and say nothing about the heap. The set of classical 
statements is Sta. For the current setting we need to redefine Ssem to map 
stores (rather than states) to Booleans (i.e. Ssem : Sta — y Store — y Bool). 

Separation logic [26] introduces a Hoare triple {P} C {Q} where P and 
Q are predicates on the state and the state is a store-heap pair (s, h). The 
function SSsem maps a separation logic statement to a predicate on states. 
Thus if SSta is the set of separation logic statements (which we haven't yet 
described) then: 

SSsem : SSta ->■ State ->■ Bool 

We call separation logic statements separation statements. 

A classical statement S can then be regarded as a separation statement 
by defining: 

SSsem S (s, h) = Ssem S s 

We now describe the separation statements that do depend on the heap. 
In what follows, E and F are expressions, which don't depend on the heap 
and have semantics given by Esem, which we assume maps expressions to 
functions on stores (i.e. Esem : Exp — y Store — y Val). P and Q will range 
over separation statements with semantics given by SSsem. We will give the 
semantics by first defining operators on the meanings of expressions and the 
meanings of statements and then, using these operators, define the meanings 
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of formulae. The variables e and / will range over the meanings of expressions 
and p and q over the meanings of statements. Thus E and F have type Exp 
but e and / have type Store ->• Val Similarly P and Q have typo SSta. but 
p and g have type State — > Bool. 

In what follows we sometimes use Boolean operators that have been 
'lifted' to act pointwise on properties, e.g. if p and q are properties of the 
state (i.e. p : State — > Bool and q : State — > Booi) then we overload -i, A, V 
and =>- by defining: 

-ip = Xstate. -i(p state) 

p A q = Xstate. p state A q state 

pV q = Xstate. p state V q state 

p =>■ q = Xstate. p state =>■ g state 

where the occurrence of ->, A, V and =>- on the left of these equations is 
lifted to operate on predicates and the occurrence on the right is the normal 
Boolean operator. The lifted operators can be used to give semantics to 
corresponding specification language constructs: 

SSsem (-.P) = ^(SSsem P) 

SSsem (P A Q) = (SSsem P) A (SSsem Q) 

SSsem (P V Q) = (SSsem P) V (SSsem Q) 

SSsem (P Q) = (SSsem P) (SSsem Q) 

Defining quantifiers for the specification language is slightly subtle. If P is a 
separation statement (normally one containing an occurrence of the variable 
X, though this is not required), then we can form statements VX. P, 3X. P 
with meaning given by: 

SSsem (VX P) {s, h) = Vu. SSsem P (s lv/X] , h) 
SSsem (3X. P) (s, h) = 3v. SSsem P (s [v/X] , h) 

An example is 3X. E i-)- X defined in the next section. 
7.3.1 Points-to relation: E i-> F 

E i— > F is true in state (s, h) if the domain of h is the set containing only the 
value of E in s and the heap maps this value to the value of F in s. 

(e /) (s, fe) = (dom h = {e s}) A (h(e s) = f s) 
SSsem (E^F) = (Esem E) ^ (Esem F) 
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The first definition in the box above defines a semantic operator (->• and the 
section definition uses this operator to give the semantics of formulae of the 
form E t-)- F. Subsequent definitions will have this form. 

Example 

The assertion X4Y+1 is true for heap {20 i-)- 43} if in the store X has value 
20 and Y has value 42. 

Points-to assertions specify the contents of exactly one location in the 
heap. Thus (using lifted A): 
(ei^/iAe 2 H>/ 2 )( s ,|j) = 
(dom h = {ei s}) A (h(ei s) = fi s) 
A 

(dom h = {e 2 s}) A (h{e 2 s) = f 2 s) 
Thus if ei i-> /1 A e 2 4 f 2 is true in a state (s, h) then e x s = e 2 s and 

h s = h s. 

Abbreviation 

We define E 1— > _ so that it is true of a state (s, h) when h is any heap whose 
domain is the singleton set {Esem E s}. 

I = 3X. (where X docs not occur in E) j 

Using the semantics of "3X" given earlier, and assuming that if X doesn't 
occur in E then Esem E (s lv/X] ) = Esem E s, we have: 

SSsem (E 1— >■ _) (s, h) 
= SSsem (3X. E m- X) (s, h) 
= 3v. SSsem (E ^ X) (slv/X],h) 
= 3v. (Esem E ^ Esem X) (s [u/X] , /i) 
= 3u. (dom /i = {Esem E (s[u/X])» A 

(/i(Esem E (s[u/X])) = Esem X (s[w/X])) 
= 3f . (dom h = {Esem E s}) A (/i(Esem E s) — v) 
= (dom /i = {Esem _E s}) A 3v. h(Esem E s) = v 
= (dom h = {Esem £s}) AT 
= (dom h = {Esem E s}) 

which shows that E _ is true of a state (s, /i) when h is any heap whose 
domain is {Esem E s}. 

The separating conjunction operator * defined below can be used to com- 
bine points-to assertions to specify heaps with bigger (i.e. non-singleton) 
domains. 
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7.3.2 Separating conjunction: P*Q 

Before defining the semantics of P * Q we need some preparatory definitions 
concerning the combination of heaps with disjoint domains. 

If hi and h 2 are heaps then define Sep hi h 2 h to be true if and only if 
the domains of hi and h 2 are disjoint, their union is the domain of h and 
the contents specified by h of a location / G dom h (i.e. h I) is the contents 
specified by hi (i.e. hi I) if I G dom hi and is the contents specified by h 2 
(i.e. h 2 I) if / G dom /i 2 - This is perhaps clearer when specified formally: 
Sep hih 2 h = 

((dom n (dom h 2 ) = {}) 

A 

((dom hi) U (dom h 2 ) = (dom /i)) 
A 

V/ G dom /i. /i I = if I G dom /ii £/ien /ii / else h 2 I 
The relation Sep hi h 2 h is usually written hi-k h 2 = h, where * is a partial 
operator that is only defined on heaps with disjoint domains. 

If (dom hi) fl (dom h 2 ) = {}, then hi * /i 2 is defined to be the union of hi 
and h 2l i.e.: 

V/ G (dom /liUdom /i 2 ). (hi~kh 2 ) I = if I G dom /i x i/ien /ii / e/se /i 2 / 
Separating conjunction also uses the ^-symbol, but as an operator to 
combine separation properties: P * Q is true in state (s, h) if there exist hi 
and h 2 such that Sep /ii h 2 h and P is true in state (s, /ii) and Q is true in 
(s, /i 2 ). We first define a semantic version: p*g where p and g are predicates 
on states and then define the specification combining operator using this. 

(p*q) (s, h) = 3hi h 2 . Sep hih 2 h A p (s, hi) A g (s, /i 2 ) 
SSsem (P*Q) = (SSsem P) * (SSsem Q) 

Note that the symbol * is used with three meanings: to combine heaps 
(hi-kh 2 ), to combine semantic predicates (p*q) and to combine separation 
statements (P*Q). 
Example 

The assertion X m- 0 * X+l m- 0 is true of the heap {20 ^0,21^ 0} if X has 
value 20 in the store. 

Abbreviation 

The following notation defines the contents of a sequence of contiguous loca- 
tions starting at the value of E to hold the values of F 0 ,. . . ,F n . 
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| E^F 0 ,...,F n = m- F 0 ) ★ • • • ★ (E+w M- F w ) | 
Example 

X i— > Y, Z specifies that if / is the value of X in the store, then heap locations 
I and l+l holds the values of Y and Z, respectively. 

We can also define a 'semantic' version of the notation which operates on 
functions: 

e^f 0 ,...J n = ( e( ->/ 0 )*...*((As. (es)+n)^f n ) 

SSsem (E H> F 0 , . . . , F n ) = Esem E H> (Esem F 0 ), . . . , (Esem F n ) 

7.3.3 Empty heap: emp 

The atomic property emp is true in a state (s, h) if and only if h is the empty 
heap (i.e. has empty domain). 

emp (s, h) = (dom h — {}) 
SSsem emp = emp 

Example 

If P is a classical property (i.e. doesn't depend on the heap) then the formula 
P A emp is true iff P holds and the heap is empty. 

Abbreviation 

We define E = F to mean that E and F have equal values and the heap is 
empty. We also define a semantic version. 

(e = /) = A(s, /*). (e s = / s) A (dom = {}) 
(E = F) — (E — F) A emp 

From these definitions it follows that: 

SSsem (£ = F) = ((Esem £) = (Esem F)). 

It also follows from the semantics that: 
Vs h. SSsem ((E = F)*P) (s, h) = 

(Esem E s = Esem F s) A Ssem P (s, ft,) 

Using lifted A notation, we can write: (e = /) *p = (e-f)Ap. 
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7.3.4 Separating implication: P -* Q 

P -* Q is true in a state (s, ft) if whenever P holds of a state (s, ft'), where 
ft' is disjoint from ft then Q holds for the state (s, ft * ft') in which the heap 
ft is extended by ft'. 

ip ~* q) ( s > M = V/i' ft". Sep ft ft/ ft" A p (s, ft') =>- g (s, ft") 
SSsem (P -* Q) = (SSsem P) -* (SSsem Q) 

We do not use separating implication here, but are mentioning it as it is 
a standard part of separation logic. 

7.3.5 Formal definition of linked lists 

If a is a list (e.g. [a, b, c] ) and e is the meaning of an expression (i.e. a 
function from stores to values) then list a e (s, ft) is defined to mean that a 
is represented as a linked list in the heap ft starting at the location specified 
by e s. The definition is by structural recursion on a: 

list [] e = (e = nil) 

list ([a 0 , ai, . . . , a n ]) e = 3e'. (e >->■ a 0 , e') * list [ai, . . . , a n ] e' 

Let List [X] be the set of lists whose elements are in X. The meaning of 
List[X] is somewhat analogous to the meaning of the regular expression X* . 
Here is type of the function list: 

list : List[Val] ->■ (Store ->■ Val) ->■ State ->■ Bool 

The definition of list above defines a semantic operator. We also use list to 
formulate separation properties. 

| SSsem (list a E) = list a (Esem E) \ 

where the occurrence of list on the left of this definition is part of the speci- 
fication language and the occurrence on the right is the semantic operator. 

Recall the informal Hoare triple given earlier to specify the list reversing 
function. 

{X points to a linked list holding a 0 } 
Y:=nil; 

WHILE -.(X = nil) DO (Z: = [X+1]; [X+l] :=Y; Y:=X; X:=Z) 

{Y points to a linked list holding rev(a 0 )} 
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Using separation logic this can be formalised as: 
{list a 0 X} 
Y:=nil; 

WHILE -.(X = nil) DO (Z: = [X+1]; [X+l] :=Y; Y:=X; X:=Z) 

{list (rev(ao)) Y} 
and the invariant for the WHILE-loop turns out to be: 

3a (5. list ttX* list (3 Y A (rev(a 0 ) = rev(a) • (3) 
where "•" is the list concatenation operator (later we also use it for list 'cons'). 

7.4 Semantics and separation logic 

In this section we give both semantics for the extended programming lan- 
guage and for Hoare logic axioms and rules for reasoning about it. 

As heap operations may fault, we define the set Result of results of com- 
mand executions to be: 

Result = State U {fault} (where it is assumed that fault ^ State) 

and then the semantic function for commands, Csem, will have the more 
general type: 

Csem : Com — >• State — y Result — y Bool 

and now Csem C (s, h) r will mean that if C is started in state (s, h) then r 
is a possible result. As mentioned earlier, we assume that expressions do not 
depend on the heap, only on the store. We also assume this about classical 
statements. Furthermore, the evaluation of neither of these can fault, thus 
we redefine: 

Esem : Exp ->■ Store -> Val 
Ssem : St a — > Store — > Bool 

For comparison, here are the various types and semantic functions for the 
previous simple semantics and then for the new heap semantics. 

Simple semantics (state maps variables to values) 

State = Var ->■ Val 

Esem : Exp ->■ State ->■ Val 
Ssem : Sta -> State -> Bool 
Csem : Com — y State —y State —y Bool 
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Heap semantics (state is 


store and heap) 


Store - 


= Var — > Val (assume Num C Val, nil e Val and nil ^ iVum) 


Heap = 


= Num -± fin Val 




State - 


= Store x Heap 




Result 


= State U {fault} 


(assume fault ^ State) 


Esem : 


Exp ->■ Store ->■ Vai 




Ssem : 


Sta — )• Store — >■ Booi 


(classical statements) 


SSsem 


: Sta ->■ State ->■ Bool 


(separation statements) 


Csem : 


Com ->■ State ->■ Resuit ->■ Booi 





The meaning of Hoare triples {P} C {Q} is subtly, but very significantly, 
different for separation logic: it is required that for the triple to be true the 
execution of C in a state satisfying P must not fault, as well as Q holding in 
the final state if execution terminates. Formally, the semantics of {P} C {Q} 
for separation logic is SHsem P C Q, where: 



SHsem P C Q = 
Vs h. SSsem P (s, h) 

=^ 

^(Csem C (s, h) fault) A Vr. Csem C (s, h) r SSsem Q r 
The function SHsem has type Sta Com — > Sta — > Bool. It is useful to 
define a semantic function shsem so that: 

SHsem P C Q = shsem (SSsem P) (Csem C) (SSsem Q) 
The definition is just: 

| shsem p c q = Vs h. p(s, h) =^> ->(c (s, h) fault) A Vr. c (s, h) r =^> qr |j 
The type of shsem is: 

(State ->• Bool) (State Result Booi) -» (State Booi) -)> Booi 
There are two reasons for the non-faulting semantics of Hoare triples: 

(i) to support verifying that programs do not read or write locations not 
specified in the precondition - i.e. memory safety; 

(ii) the non-faulting semantics is needed for the soundness of the crucial 
Frame Rule for local reasoning, which is discussed later. 

Non-faulting should not be confused with non-termination: the non-faulting 
requirement is a safety property ( "nothing bad happens" ) not a liveness prop- 
erty ("something good happens"). Separation logic can straightforwardly be 
extended to total correctness - a liveness property - but we do not do this. 
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The semantics we give here is equivalent to the large-step operational se- 
mantics of Yang and O'Hearn [25, Table 2], but presented in the denotational 
style used in Chapter 4 for the simple language. With the semantics given 
here, proofs are done by structural induction for loop-free commands plus 
mathematical induction for WHILE-commands. With an operational seman- 
tics, the equivalent same proofs are done using rule-induction. 

For each construct we give the semantics followed by the separation logic 
axiom schemes or rules of inference. It is only the axiom schemes for the 
atomic commands that read or modify the heap that are new. The rules 
for sequences, conditionals and WHILE-commands remain the same (the non- 
faulting semantics makes their soundness justification slightly more complex). 

7.4.1 Purely logical rules 

From the definition of SHsem it follows that the rules of consequence, i.e. pre- 
condition strengthening and postcondition weakening are sound by logic 
alone: their soundness doesn't depend on the semantics of commands. 



Rules of consequence 

h P =» P', h {P'} C {Q} 
h {P} C {Q} 

h {P} C {(?}, h Q'^Q 
h {P} C {Q} 



Another rule that follows from the definition of SHsem (and also from 
that of Hsem) is the following. 



Exists introduction 

h {3x. P} C {3x. Q} 
where x does not occur in C 



Although valid for ordinary Hoare logic, this is not much use there. However, 
it is very useful in separation logic, as we shall see in Section 7.8. 
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7.4.2 Semantics of store assignments 

Store assignments V : =E were in the earlier language without pointers. They 
ignore the heap and always succeed. 

| Csem (V : =E) (s, h) r = (r = (s [(Esem E s)/V] , h)) \ 

Note that s here ranges over stores not states, thus in the above semantic 
equation: s G Store, h G Heap, (s, h) G State and r G Result. 

7.4.3 Store assignment axiom 

First recall the classical Hoare assignment axiom scheme: 

h {Q[E/V]}V:=E{Q} 

Although this is sound for separation logic, it is not the axiom usually given 
[26] - a 'small' Floyd-style forward axiom is used instead. This style of axiom 
is also used for all the axioms below. Perhaps the reason for this forward 
'strongest postcondition' style is because it connects more directly with sym- 
bolic execution, which is a technique widely used by program analysis tools 
based on separation logic. 

Store assignment axiom 

h {V = v}V:=E {V = Elv/V]} 
where v is an auxiliary variable not occurring in E. 

Note that the meaning of = forces any state for which the precondition is 
true to have an empty heap. Store assignments do not fault, so this is sound. 

If V does not occur in E, then, as (V = V) = emp and E[V/V~\ = E it 
follows that the following is a derived axiom: 

h {emp} V:=E {V = E} (where V doesn't occur in E) 

Another derived axiom is obtained using the exists introduction rule to 
obtain the following from the store assignment axiom: 

h {3v. V = v}V:=E {3v. V = E[v/V]} 

The precondition of this is emp. This follows from the definitions of = and 
lifted quantification: 
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(3v. V = v)(s, h) = 3v. (s V = v s) A (dom h = {}) 

The statement 3v. (s V = v s) is true - to see this take v to be As. s V - 
hence (3v. V = v ) = emp and so the following is a derived axiom: 

h {emp} V:=E {3v. V = E[y/V\} (where v doesn't occur in E) 

7.4.4 Semantics of fetch assignments 

Fetch assignments change the store with the value of a location in the heap, 
faulting if the location is not in the heap. They do not change the heap. 

Csem (y : = [£]) {s,h) r = 

(r = if Esem E s E dom(/i) then (s[/i(Esem E s)/Esem E s],h) else fault) 

In the above semantic equation: s G Store, h G Heap, (s, h) G State and 
r G Result. 

7.4.5 Fetch assignment axiom 

Fetch assignment axiom 

h {(V = Vl ) AE ^v 2 }V : = [£] {(V = v 2 ) A E IvJV] ^ v 2 } 

where v\, v 2 are auxiliary variables not occurring in E. 

Like the store assignment axiom above, this is best understood as describing 
symbolic execution. Note that the precondition requires the heap to contain 
a single location given by the value of E in the store and whose contents is v 2 . 
After the fetch assignment, the variable V has the value v 2 in the store and the 
heap is unchanged (because the value of E [vi/V] in the postcondition state 
is the same as the value of E in the precondition state). The precondition 
ensures that the fetch assignment won't fault since the value of E is specified 
by E i — y v 2 to be in the heap. 

7.4.6 Semantics of heap assignments 

Heap assignments change the value of a location in the heap, faulting if the 
location is not in its domain. The store is unchanged. 

Csem (IE J :=E 2 ) (s,h) r = 

(r = if Esem E x s G dom(/i) then (s, MEsem E 2 s/Esem E x s] ) else fault) 
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7.4.7 Heap assignment axiom 

Heap assignment axiom 

h {E i-)- _} IE] :=F{E^F} 

This is another forward symbolic execution style axiom. The precondition 
asserts that domain of the heap consists of the value of E in the store and 
thus the heap assignment does not fault. 

7.4.8 Semantics of allocation assignments 

Allocation assignments change both the store and the heap. They non- 
deterministically choose n contiguous locations, say /, /+1, . . . , l+(n— 1), that 
are not in the heap (where n is the number of arguments of the cons) and 
then set the contents of these new locations to be the values of the arguments 
of the cons. Allocation assignments never fault. 



Csem (V :=cons(£i,. . .,£„)) (s,h) r = 
31. I g dom(/i) A • • • A Z+(ra-l) i dom(/i) A 

(r = (s ll/V] , h [Esem E 1 s/Z] • • • [Esem E n s/Z+(n-l)] )) 



This is non-deterministic because Csem (V :=cons(£'i, . . . , E n )) (s,h) r is 
true for any result r for which the right hand side of the equation above 
holds. As the heap is finite, there will be infinitely many such results. 



7.4.9 Allocation assignment axioms 



Allocation assignment axioms 




h {V = v}V:=cona(E 1 ,...,E n ) {V i-)- E x [v/V~\ , 


..,E n [v/V] } 


where v is an auxiliary variable not equal to V. 




h {emp}V:=cons(E 1 ,...,E n ){V^E 1 ,. 




where V is an auxiliary variable not occurring in E 1 ,. . 


;E n . 



116 



Chapter 7. Pointers and Local Reasoning 



These are also forward symbolic execution style axioms - but they are non- 
deterministic. The preconditions assert that the heap is empty In the first 
axiom, the precondition also specifies that V has value v in the store. The 
postconditions use the abbreviation in Section 7.3.2 for specifying a contigu- 
ous chunk of memory and asserts that the domain of the heap is n contiguous 
locations which contain the values of Ei, - ■ ■ ,E n in the precondition store. No- 
tice that this axiom does not determine that value of V after the assignment 
- so is non-deterministic - it merely requires that V points to any location 
not in the heap before the command is executed. 

7.4.10 Semantics of pointer disposal 

Pointer disposals deallocate a location by deleting it from the heap's domain, 
faulting if the location isn't in the domain. The store is unchanged. 

Csem (dispose (E)) (s,h) r = 

(r = if Esem E s e dom(/i) then (s, /i-(Esem E s)) else fault) 



7.4.11 Dispose axiom 

Dispose axiom 

h {E M- _} disposed) {emp} 



Requires the heap to contain only one location and then deallocates it re- 
sulting in the empty heap. 

7.4.12 Semantics of sequences 

If neither C\ nor C 2 faults then the semantics of C\ ; C 2 is as before. If either 
Ci or C 2 faults, then so does C\ ;C 2 . 

Csem (Ci;C 2 ) (s,h) r = 
if (3s' h'.r = {s\h')) 

then (3s' h'. Csem C\ (s, h) (s' } h') A Csem C 2 (s 1 , h') r) 
else ((Csem C x (s, h) r A (r = fault)) 

V 

3s' h'. Csem d (s, h) (s', h') A Csem C 2 (s', h') r A (r = fault)) 



7.4. Semantics and separation logic 
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7.4.13 The sequencing rule 

The sequencing rule is unchanged for separation logic. Note that if the 
hypotheses are true, then there is no faulting. 

The sequencing rule 

h {P} d {Q}, h {Q} d {R} 
\~ {P}C l ;C 2 {R} 

The proof of soundness of the sequencing rule is straightforward. The argu- 
ment is similar to the one given for simple Hoare logic in Section 4.2 with 
some additional arguments to handle faults. One proves: 
Vp q r ci c 2 . 
shsem pqrA shsem r c 2 q 

shsem p (A(s, h) r. 3s' ti . c\ (s, h) (s', h') A c 2 (s', h') r) q 
where shsem is the semantic function representing the meaning of separation 
logic Hoare triples which was defined on page 111. 

7.4.14 Semantics of conditionals 

The semantics of conditionals is as before (see Section 4.1.2). 

Csem (IF S THEN d ELSE C 2 ) (s, h) r = 
if Ssem S s then Csem d (s, h) r else Csem C 2 (s, h) r 

7.4.15 The conditional rule 

The conditional rule is unchanged. 

The conditional rule 

h {PAS} d {Q}, h {PA -^S} C 2 {Q} 
h {P} IF S THEN d ELSE C 2 {Q} 

The proof of soundness of the conditional rule is straightforward. One proves: 
Vp q b ci c 2 . 
shsem (pAb) c x q A shsem (p A -b) c 2 q 

^> 

shsem p (A(s, h) r. if b(s, h) then c\ (s, h) r else c 2 (s, h) r) q 
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Notice that in (p A b) and (p A ->b) the conjunction A and negation -> are 
lifted (see page 105). 

7.4.16 Semantics of WHILE-commands 

The semantics of WHILE-commands is similar to the one given in Section 4.1.2 
except that if a fault arises during the execution then the iteration aborts 
with a fault. 

|Csem (WHILE S DO C) (s,h) r = 3n. Item (Ssem S) (Csem C) (s,h) r \ 
The function Iter is redefined to handle faulting: 
Iter 0 p c (s,h) r = ->(p s) A (r = (s, h)) 

Iter (n+1) p c (s,h) r = 
psA(tf(3s' h'.r = {s'h')) 

then (3s' h! . c(s, h)(s'ti) A Iter n p c (s', h!) r) 

else ((c (s,h) r A (r = fault)) 

V 

3s' hi . c (s, h) (s', h!) A Iter n p c (s', h!) r A (r = fault))) 
The type of Iter is: 

Iter : Num^(Store^Bool)^(State^Result^Bool)^State^Result^Bool 

7.4.17 The WHILE-rule 

The WHILE-rule is unchanged. 

The WHILE-rule 

h {PAS}C {P} 
h {P} WHILE S DO C {P A ~^S} 

The semantics of WHILE commands is defined in terms of the function Iter. 
The following two lemmas about Iter are straightforward to prove by induc- 
tion on n. 

shsem (p A b) c p =^ Vn s h. p(s, h) =^ — <(lter n b c (s, h) fault) 
shsem (p A b) c p 

Vn s h s' /i'. p(s, /i) A Iter n b c (s, h) (s', /i') ^> p(s', /i') A ->(b(s', h')) 
Notice that in (pA6) the conjunction A is lifted. The soundness of the WHILE 
rule follows easily from these lemmas. 
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7.5 The frame rule 

The frame rule is the key rule of separation logic. The motivation given 
here is based on the account in Reynolds' notes [23]. The purpose of the 
frame rule is to enable local reasoning about just those locations that a 
command reads and writes to be extended to uninvolved locations, which 
are unchanged. How to handle this gracefully is the so called frame problem 
that was identified 50 years ago as a problem in using logic to model actions 
in artificial intelligence. 2 

The following rule, which Reynolds calls the rule of constancy, holds in 
the simple language without a heap (the proof is by structural induction on 
C). A variable V is said to be modified by C is it occurs on the left of : = 
in a store, fetch or allocation assignment in C (variables on the left of heap 
assignments are not modified). 

The rule of constancy 

t {P)C{Q} 
h {P A R} C {Q A R} 
where no variable modified by C occurs free in R. 



this is not valid for heap assignments because although by the heap assign- 
ment axiom: 

h {X^_} [X] :=0{X^0} 

the following is not true (since X = Y is a possibility): 

{X^ _ A 1} [X] :=0 {X^ 0 A Y^ 1} 

They key insight, attributed to O'Hearn by Reynolds, is to use * instead of 
A to ensure that the added assertion R is disjoint from P and Q. This gives 
rise to the frame rule below: 

The frame rule 

t {P}C{Q} 
h {P*R}C{Q*R} 
where no variable modified by C occurs free in R. 

2 http : //en . wikipedia . org/wiki/Frame_problem 



120 



Chapter 7. Pointers and Local Reasoning 



In the frame rule a variable V is said to be modified by C is it occurs on the 
left of := in a store, fetch or allocation assignment in C. 

The proof that the frame rule is sound is quite tricky and depends on the 
no-faulting semantics of Hoare triples. The key lemmas are Monotonicity: 

MC s h 0 h h 2 . 

-.(SHsem C (s, h 0 ) fault) A Sep h 0 h x h 2 ->(SHsem C (s, h 2 ) fault) 

and The Frame Property: 
VC s s' h 0 hi h 2 h'. 

^(SHsem C (s, h 0 ) fault) A SHsem C (s, h 2 ) (s f , h') A Sep h 0 h h 2 

3h' 0 . SHsem C (s, hO) (s', h' 0 ) A Sep h' 0 h x h! 

For further details of what these lemmas mean and why they are key to 
the soundness of the fame rule see the original paper [25]. Notice that in 
these two lemmas the quantification is over commands C, not over arbitrary 
functions c : State — > Result — >■ Bool. This is because the lemmas do not 
hold for arbitrary functions, only for functions that are the meaning of com- 
mands (e.g. for Csem C). Abstract separation logic assumes these lemmas 
as axioms and then develops a generalised version of separation logic that 
can be instantiated to different models of states. The original paper on ab- 
stract separation logic [30] provides more details. See also recent research 
by Thomas Tuerk [31] on using abstract separation logic as a framework for 
building mechanised program verification tools. 

7.6 Example 

The informal Hoare triple: 

{contents of pointers X and Y are equal} X: = [X] ; Y: = [Y] {X = Y} 
can be formalised as 

{3v. X4» *Y^v} X: = [X] ; Y: = [Y] {X = Y} 
By the fetch assignment axiom: 

h {(X = x) A X m- v} X : = [X] {(X = v) A x M- v} 
h {(Y = y) A Y H> v} Y : = [Y] {(Y = v) A y H> v} 
By the frame rule: 
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h {((X = rr) AX^t;)*((Y = i/) AY^t))} 
X: = [X] 

{((X = u)Ai4d)* (((Y = y) A Y 4 u))} 

h {((Y = i/)AY4«)*((X = i;)Ai4«)} 
Y: = [Y] 

{((Y = v) A y i-> v) * ((X = u) A x M- u)} 
Hence by the sequencing rule and the commutativity of the * operator (see 
next section): 

h {((X = i)AX^^((Y = i/)AY^d)} 
X: = [X] ;Y: = [Y] 

{((X = v) A x t-» u) * ((Y = u) A y H> v)} 

Next use the exists introduction rule three times to get: 

h {3v x y. ((X = x) A X m- u) ★ ((Y = y) A Y m- u)} 
X: = [X] ;Y: = [Y] 

a; y. ((X = v) A i 4 v) * ((Y = i>) A y i— >■ w)} 

The following implications are true (we say more on why later): 

(3v. X^t;*YKt)) =>• 3vxy. ((X = x) A X H> u) ★ ((Y = y) A Y H> v) 
(3v x y. ((X = v) Ax^v)*((Y = v) Ay^v)) (X = Y) 

Hence by the rules of consequence: 

h {3f . X H' t) * Y 14 t)} X : = [X] ; Y : = [Y] {X = Y} 

This proof seems rather heavy for such a trivial result, but, as we have seen 
for simple Hoare logic, derived rules and automation can eliminate most of 
the fine details. In the next section we say more about proving formulae like 
the two implications we used with the rules of consequence in the last step. 

7.7 The logic of separating assertions 

In simple Hoare logic the assertion language consists of standard predicate 
calculus formulae and thus the standard deductive system of predicate logic 
can be used to prove formulae, e.g. when needed for applying the rules of 
consequence. Alternatively one can take a semantic view and regard asser- 
tions as predicates on the state and then just use 'ordinary mathematics' to 
prove assertions. 

In separation logic there are additional operators such as * and 1-4 which 
are not part of standard logic. One can try to develop a deductive system 
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for such operators and then prove properties of the assertions, but (as far as 
I know, e.g. [28]) there is no complete deductive system for such assertions. 
One can accumulate a collection of ad hoc rules for doing proofs, but, as 
Reynolds says in his notes [23] these are likely to be "far from complete", 
though they might be good enough for most examples that come up in prac- 
tice. In the last section it was asserted that the following two implications 
were true: 

(3v. X H> v * Y H> v) 3v x y. ((X = x) A X H> v) * ((Y = y) A Y H> v) 
(3v x y. ((X = !))Ai4d)* ((Y — v)Ayt-> v)) (X = Y) 

To verify that these are true one must show that they hold for all states (s, h) 
- i.e. that Vs h. SSsem P (s, h). One could just prove this directly from the 
definitions, but an alternative is to use derived laws for the separation logic 
operators to prove the assertions 'algebraically'. For example, the following 
equations can be derived from the definition of * (see Section 7.3.2): 

3x. Pi * P 2 = Pi * (3x. P 2 ) (when x not free in Pi) 

3x. Pi*P 2 = (3x. Pi) * P 2 (when x not free in P 2 ) 

hence: 

3v x y. ((X = x) A X ^ v) * ((Y = y) A Y ^ v) 
= 3v. (3x. (X = x) A X m- v) * (3y. (Y = y) A Y m- v) 
= 3v. ((3x. X = x)AX^«)i ((3y. Y = y)AY^v) 
= 3d. (TAX^t))i(TAY^t>) 
= 3v. v*Y v 

This establishes the first implication (actually it establishes a stronger result: 
an equation rather than an implication). 

To prove the second implication, first start by a similar calculation to the 
one above: 

(3v x y. ((X = v) A x \-> v) * ((Y = v) A y \-> v)) 
= 3v. ((X = v) A (3x. x i y v) ) ic ((Y — v) A (3y. y i— >■ «)) 

We say a property is /ieap independent if it doesn't depend on the heap. The 
classical statements discussed in Section 7.3 are heap independent. Semanti- 
cally P is heap independent iff Vs /i x h 2 . P(s, hi) = P(s, h 2 ). The following 
law is then true: 



((Pi A Qi) * (P 2 A Q 2 )) (Pi A P 2 ) (Pi, P 2 heap independent) 
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The values of variables don't depend on the heap, so both X = v and Y = v 
are heap independent. Thus: 

(3v. ((X = v) A (3z. x i— >• v)) * ((Y = u) A (3y. j/ i— >■ «))) 
3u. (X = v) A (Y = u) 
X = Y 

This completes the proof that: 

(3uxy. ((X = v) Ax^v)*((Y = v) Ay^v)) => (X = Y) 

7.8 The list reversal program 

In this section we take a preliminary look at the list reversing program dis- 
cussed earlier. Further details (e.g. a full proof) may be added to a future 
version of these notes. A proof outline can be found in Reynolds notes [23] . 
The Hoare triple to be proved is: 

{list a 0 X} 
Y:=nil; 

WHILE -.(X = nil) DO (Z: = [X+1] ; [X+l] :=Y; Y:=X; X:=Z) 
{list (rev(ao)) Y} 

We previously mentioned that "•" is the list concatenation operator (we will 
also write a ■ a for the result of 'consing' an element a onto a). The invariant 
given by Reynolds in his notes is: 

3a 0. list a X* list 0 Y A (rev(ct 0 ) = rev(a) ■ f3) 

We need to show that: 

1. this holds just before the loop is entered; 

2. it is indeed an invariant; 

3. with the loop exit condition X = nil it implies list (rev(ao)) Y. 



| What follows has not been fully checked and may contain errors! 

To show 1 we need to prove: 

{list a 0 X} Y:=nil {3a 0. list a X ★ list f3 Y A (rev(a 0 ) = rev(a) ■ f})} 
By the store assignment axiom: 
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h {Y = f} Y : =nil {Y = nil [i>/Y] } 
hence, as Y doesn't occur in nil: 

h {Y = v} Y:=nil {Y = nil} 
By the definition of list (base case): list [] e = (e = nil) 

h {Y = v} Y:=nil {list [] Y} 
By the frame rule (and commutativity of *): 

h {list a 0 X * (Y = v)}Y:=n\\ {list a 0 X* list [] Y} 
Clearly rev(a 0 ) = i"ev(a 0 ) • H, so: 

h {list a 0 X * (Y = v)} Y:=nil {list a 0 X* list [] Y A (rev(a 0 ) = rev(a 0 ) • [])} 
By exists introduction (see Section 7.4.1): 

h {3v. list a 0 X* (Y = v)} Y:=nil {3v. list a 0 X * list [] Y A (rev(a 0 ) = rev(a 0 ) • 
Let us assume the following two purely logical implications: 
(Pl.l) h list a 0 X =>■ 3v. list a 0 X * (Y = v) 
(P1.2) h (3u. list a 0 X ★ list [] Y A (rev(a 0 ) = rev(a 0 ) • [])) 
(3a f3. list a X* list /3 Y A (rev(a 0 ) = rev(a) • /?)) 
From Pl.l and PI. 2, the result of exists introduction above and the conse- 
quence rules: 

{list a 0 X} Y:=nil {3a (3. list a X* list £ Y A (rev(a 0 ) = rev(a) • /?)} 
which is 1. 

To show 2 we need to prove: 

{(3a /3. list aX* list (3 Y A (rev(a 0 ) = rev(a) • /?)) A -.(X = nil)} 

Z : = [X+l] ; [X+l] : =Y; Y : =X; X : =Z 

{3a /3. list aX* list (3 Y A (rev(a 0 ) = rev(a) • 0)} 
which we do by proving the following three statements and then using the 
Sequencing Rule. 

{(3a /3. list aX* list [3 Y A (rev(a 0 ) = rev(a) • /?)) A -.(X = nil)} 
Z: = [X+1] 

{3a a (3. X n> a, Z * list aZ* list [3 Y A (rev(a 0 ) = rev(a • a) • (3)} 

{3a a (3. X n> a, Z * list aZ* list [3 Y A (rev(a 0 ) = rev(a • a) • /?)} 
[X+l] :=Y 

{3a /3. list a Z * list (3 X A (rev(a 0 ) = rev(a) • /?)} 
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{3a (3. list «Z* list (3 X A (rev(a 0 ) = rev(a) • (3)} 
Y:=X;X:=Z 

{3a p. list a X* list (3 Y A (rev(a 0 ) = rev(a) • /?)} 
The last of these follows by two applications of the ordinary Hoare assignment 
axiom and the sequencing rule. The first two are more tricky, and require 
the fetch and heap assignment axioms, respectively. Recall: 

Fetch assignment axiom 

h {(V = Vl ) AE ^v 2 }V : = [£] {(V = v 2 ) AE[ Vl /V] v 2 } 

where v\, v 2 are auxiliary variables not occurring in E. 

The instance of this we need is: 

h {(z = Vi) AX+1 H> v 2 } Z: = [X+1] {(Z = v 2 ) A X+l [f i/Z] m- w 2 } 

As Z does not occur in X+l we have X+l [v i/Z] = X+l. The variable t>i serves 
no useful role here, so we can eliminate it by instantiating it to Z. We also 
rename the logical variable v 2 to /. Thus: 

h {X+l ^ 1} Z : = [X+l] {(Z = I) A X+l H> /} 

This is a local property just describing the change to a one-element heap 
(containing X+l). From this, we must somehow deduce a global property 
about the whole list. Let : 

R = x^a* list a' I * list (3 Y A (rev(a 0 ) = rev(a • a') ■ (3) A -i(X = nil) 

The process of finding this R is related to abduction, a kind of frame inference 
that is a hot topic in recent research [4]. By the frame rule, followed by 
repeated applications of the exists rule: 

h {3a (3 a I a'. X+l H> / * R} Z : = [X+l] {3a (3 a I a', (z = I) A X+l H> Z * 

From this we need to deduce: 

h {(3a 0. list a X * list (3 Y A (rev(a 0 ) = rev(a) • /?)) A -.(X = nil)} 
Z: = [X+1] 

{3a a f3. a,Z-k list aZ* list [3 Y A (rev(a 0 ) = rev(a ■ a) ■ (3)} 
which can be done using the consequence rules if P2.1 and P2.2 below hold: 
(P2.1) h (3a /3. (list aX* list (3 Y A (rev(a 0 ) = rev(a) • /?)) A -.(X = nil 
=^> 3a (3 a I a', (x+l H> I) * R 

(P2.2) h {3a (3 a I a', ((z = I) A X+l K I) 

=^> 3a a /3. X i-)- a, Z ★ list a Z ★ list [3 Y A (rev(a 0 ) = rev(a • a) 
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These are purely logical properties (in the assertion language of separation 
logic). Their proof uses the definition of the list predicate list and logical 
reasoning. Recall the list predicate: 



list [] e = (e = nil) 

list ([ao, ai, . . . , a n \) e = 3e'. (e a 0 , e') * list [ai, . . . , a n \ e' 



where 

| E^F 0 ,...,F n = (E t-^ F 0 ) ★ ■ ■ ■ * (E+n 



list [] e = (e = nil) 

list ([a 0 , ai, . . . , a n \) e = 3e'. (e a 0 ) * (e+1 )->• e') * list [ai, . . . , a n ] e' 



Arguing informally: from list a X and -<(X = nil) it follows that for some 
value a and a' we have a = a ■ a'. From this rev(a 0 ) = rev(a -a')- (3 and from 
list a X there exists a location / such that X »->■ a, X+l / and list a' /. Thus: 

h (list aX* list (3 Y A (rev(a 0 ) = rev(a) • /?)) A -.(X = nil) 
=^ 

((3a I a'. 

X^a*X+l^l* list a' I * list /3 Y 

A (rev(a 0 ) = rev(a • a') • /?)) A -.(X = nil)) 

The first of the two needed logical properties follows from this using some 
quantifier movement and the commutativity of *. The second property re- 
quires the list predicate to be unfolded. 
This concludes a sketch of the proof of the first Hoare triple: 

{(3a /3. list aX* list (3 Y A (rev(a 0 ) = rev(a) • /?)) A -.(X = nil)} 
Z: = [X+1] 

{3a a (3. X n> a, Z * list aZ* list [3 Y A (rev(a 0 ) = rev(a • a) ■ j3)} 

The remaining Hoare triple is: 

{3a a 13. X !->■ a, Z * list «Z* list (3 Y A (rev(a 0 ) = rev(a . «) . (3)} 
[X+l] :=Y 

{3a (3. list «Z* list (3 X A (rev(a 0 ) = rev(a) • /?)} 
To prove this we need the heap assignment axiom: 
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Heap assignment axiom 

h {E^_} [El :=F{E^F} 

The appropriate instance is: 

h {3v. X+l i-> v} [X+l] :=Y {X+l i— >■ Y} 

By inventing a suitable frame, application of the frame rule and some logical 
fiddling, including using the definition of list, one deduces from this: 

h {3a a p. X !->• a, Z * list a Z * list f3 Y A (rev(a 0 ) = rev(a ■ a) ■ (3)} 
[X+l] :=Y 

{3a a p. XH>a,Y*list a Z ★ list /3 Y A (rev(a 0 ) = rev(a • a) • p)} 
and then one gets the desired result by postcondition weakening using: 

(P2.3) h (3a a p. X H> a, Y ★ list a Z * list /3 Y A (rev(a 0 ) = rev(a • a) ■ (5)) 

(3a p. list «Z* list /3 X A (rev(a 0 ) = rev(a) • (5)) 
which is proved by first proving: 

(P2.3.1) h (3a a /3. X^ a, Y* list a Z ★ list p Y A (rev(a 0 ) = rev(a • a) • p)) 

(3a a /3. list a Z * list (a • /3) X A (rev(a 0 ) = rev(a) • a • /?)) 

and then proving 

(P2.3.2) h (3a a (3. list a Z* list (a • /3) X A (rev(a 0 ) = rev(a) • a • /?)) 

(3a /3. list a Z* list /3 X A (rev(a 0 ) = rev(a) • p)) 
and then using the transitivity of implication (=>•). 

Finally, to show 3 (i.e. invariant and loop exit condition X=nil implies 
list (rev(a 0 )) Y) we need to prove property P3, where: 

(P3) h (3a p. list a X * list p Y A (rev(a 0 ) = rev(a) • /?)) A (X = nil) 

list (rev(a 0 )) Y 

Which, again, is fiddly pure logic using the definition of the list predicate 
list. 

Proofs like the one sketched above, are normally shown as 'proof outlines' 
which are a similar to annotated programs. Reynolds' proof outline for the 
list reversing example [23] is (with some renaming of variables and other 
minor changes): 
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{list a 0 X} 
Y:=nil; 

{3a /3. list a X* list [3 Y A (rev(a 0 ) = rev(a) • /?)} 

WHILE (X=nil) DO {3a (3. list aX* list [3 Y A (rev(a 0 )=rev(a) • (3)} 

({3a /3. list aX* list (3 Y A (rev(a 0 )=rev(a) • /3) A -.(X=nil)} 

{3a (3 a I a 1 . 

(X+1 ^l)*x^a* list a' Z * list /3 Y A (rev(a 0 )=rev(a • a') ■ fS) A ->(X=nil)} 
Z: = [X+1] ; 

{3a (3 a I a'. 

((Z=Z) AX+mI)*X^o* list a' I * list /3 Y A (rev(a 0 )=rev(a • a') ■ (3) A -i(X=nil)} 
{3a a (3. a,Z* list aZ* list (3 Y A (rev(a 0 ) = rev(a • a) • /?)} 
[X+1] :=Y; 

{3a a (3. XH>a,Y*list a Z ★ list (3 Y A (rev(a 0 ) = rev(a • a) • /?)} 
{3a a /3. list aZ* list (a • /?) X A (rev(a 0 ) = rev(a) ■ a ■ (3)} 
{3a /3. list aZ* list /3 X A (rev(a 0 ) = rev(a) • (3)} 
Y:=X; X:=Z 

{3a (3. list dX* list (3 Y A (rev(a 0 ) = rev(a) • /?)}) 
{list (rev(a 0 )) Y} 

Proof outlines like this are superficially similar to annotated Hoare triples as 
described for verification condition generation. They do specify what has to 
be done to get a complete proof, namely: 

• prove h P =>■ Q for each sequence of sentences {P}{Q}; 

• prove h {P} C {Q} for each occurrence of a Hoare triple. 
However, proving these is not always straightforward or mechanisable. 

• There is no established methodology for proving P =>■ Q when P, Q are 
arbitrary assertions of separation logic - one relies on manual methods 
from incomplete sets of axioms and rules, or decision procedures for 
weak subsets. 

• The assignment axioms of separation logic only support local reason- 
ing about the sub-heaps involved - one needs to the extend local Hoare 
triples given by the axioms to global ones using the frame rule, and find- 
ing the right frame to use is tricky and heuristic, somewhat analogous 
to finding invariants, rather than algorithmic (it's related to abduc- 
tion [4]). 



7.8. The list reversal program 
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Thus proof outlines are (currently) mainly an informal notation for writing 
down hand proofs. 

Mechanising separation logic is an active research area. Most success 
so far has been on just verifying shape properties (i.e. shape analysis). The 
classic work is a tool called Smallfoot (google Smallf oot Berdine). A recent 
project at Cambridge to mechanise reasoning about the content of data- 
structures, rather than just their shape, is Holfoot (google Holf oot Tuerk). 

In addition to the mechanisation of separation logic, there is much cur- 
rent research on extending the logic to support mainstream programming 
methods, like concurrency and object-oriented programing. 



Chapter 7. Pointers and Local Reasoning 
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